v0.2.47..v0.2.48 changeset ProcessingError.asciidoc

diff --git a/docs/algorithms/ProcessingError.asciidoc b/docs/algorithms/ProcessingError.asciidoc
index d6c1c24..66b2e02 100644
--- a/docs/algorithms/ProcessingError.asciidoc
+++ b/docs/algorithms/ProcessingError.asciidoc
@@ -1,10 +1,10 @@
 
 == Sources of Processing Error
 
-This document explores some of the sources of errors while processing geospatial 
-data in Hootenanny and quantifies those errors in specific test cases. Any large 
-and intentional changes that may occur as a result of destructive operations, such 
-as snapping nodes together to create  intersections, averaging ways, or rubber 
+This document explores some of the sources of errors while processing geospatial
+data in Hootenanny and quantifies those errors in specific test cases. Any large
+and intentional changes that may occur as a result of destructive operations, such
+as snapping nodes together to create  intersections, averaging ways, or rubber
 sheeting data together are considered outside of the scope of this current effort.
 
 === Sources of Small Geometry Changes
@@ -91,11 +91,11 @@ The following transformations were tested:
 ==== Results
 
 The graph and tables below show a number of operations that can impact
-processing error in Hootenanny. 
+processing error in Hootenanny.
 
 [[processingerrorgraph]]
 .Graph of mean and max distance errors in log scale.
-image::algorithms/images/ProcessingErrorGraph.png[Graph of mean and max distance errors in log scale,scalewidth="50%"]
+image::images/ProcessingErrorGraph.png[Graph of mean and max distance errors in log scale,scalewidth="50%"]
 
 .Table of movement errors and distance errors in nanodegrees.
 [options="header"]
@@ -127,13 +127,13 @@ image::algorithms/images/ProcessingErrorGraph.png[Graph of mean and max distance
 |Save to .gml|553|0|0.00076|0.00326|0.00082
 |======
 
-Over the course of testing the largest error found was approximately 15mm. 
-While compared to the other errors introduced this is large, but it is quite 
-small in the context of 15m accuracy road data. This error was also easy to 
+Over the course of testing the largest error found was approximately 15mm.
+While compared to the other errors introduced this is large, but it is quite
+small in the context of 15m accuracy road data. This error was also easy to
 reduce to 155um by simply changing the default setting in the file format.
 
-Outside of the .osm.pbf file format the errors are down in the nanometer range, 
-although there are still unintentional changes occurring in the data. 
+Outside of the .osm.pbf file format the errors are down in the nanometer range,
+although there are still unintentional changes occurring in the data.
 
 ==== Conclusions
 
@@ -164,8 +164,8 @@ services such as Google and Bing.
 
 [[ui-interactions]]
 .User Interface Interactions
-[graphviz, tmp/UiInteractions.png, fdp]
----------------------------------------------------------------------
+[graphviz, images/UiInteractions.png, fdp]
+--------------------------------------------------------------------
 digraph G
 {
 dpi=96;
@@ -184,7 +184,7 @@ core -> db;
 services -> db;
 ui -> services [label="RESTful XML\n(WGS84 as Text)"];
 }
----------------------------------------------------------------------
+--------------------------------------------------------------------
 
 In the above you can see that the _Hoot Core_ (where all algorithmic code
 resides) communicates directly with the database for reading and writing of
@@ -194,15 +194,15 @@ The _Web Services_ communicate directly with the database for serving data out
 via web service calls. The _Web Browser_ (Hootenanny User Interface) communicates with the _Web
 Services_ over HTTP to request data and post changes.
 
-The latitude/longitude data is stored in the database as 64 bit double precision floating point 
+The latitude/longitude data is stored in the database as 64 bit double precision floating point
 values. All values are stored in the Database in the WGS84/EPSG:4326 projection and have an accuracy
-of 0.01 nanodegrees.  Of note, is the fact that OpenStreetMap's default accuracy is 100 nanodegrees, 
+of 0.01 nanodegrees.  Of note, is the fact that OpenStreetMap's default accuracy is 100 nanodegrees,
 and it stores coordinates as 64 bit integers.
 
-When _Hoot Core_ writes data to the DB, no significant error should be introduced.  This has not 
-been tested experimentally, but some informal testing with Washington, D.C. streets data has 
-revealed no measurable error in QGIS between data imported into the database and then exported and 
-data read straight from an OSM file.  Please see <<SelectingAProjection>> for more details on 
+When _Hoot Core_ writes data to the DB, no significant error should be introduced.  This has not
+been tested experimentally, but some informal testing with Washington, D.C. streets data has
+revealed no measurable error in QGIS between data imported into the database and then exported and
+data read straight from an OSM file.  Please see <<SelectingAProjection>> for more details on
 how projections are utilized within the core.
 
 To serve data out over web services the services read the data from the
@@ -226,6 +226,6 @@ exhaustively explored, but the initial indication is that enough significant
 digits are represented to prevent additional error from being introduced during
 the process of posting changesets.
 
-The posted changeset is processed by the web services and the values are stored as 64 bit double 
-precision floating point values in the database as WGS84/EPSG:4326. The changeset is already in 
+The posted changeset is processed by the web services and the values are stored as 64 bit double
+precision floating point values in the database as WGS84/EPSG:4326. The changeset is already in
 WGS84/EPSG:4326 so no addition change in projection is necessary.