v0.2.47..v0.2.48 changeset DifferentialConflation.asciidoc

diff --git a/docs/algorithms/DifferentialConflation.asciidoc b/docs/algorithms/DifferentialConflation.asciidoc
index 22cb6f4..9a81b48 100644
--- a/docs/algorithms/DifferentialConflation.asciidoc
+++ b/docs/algorithms/DifferentialConflation.asciidoc
@@ -5,13 +5,13 @@
 
 Differential Conflation makes use of the Unifying conflation framework within
 Hootenanny, but attempts a much simpler operation than "full" conflation. The
-idea is to allow a user to take two datasets, A and B, and generate a 
-changeset from them such that the changeset includes all of the data in 
-set B that does not overlap (conflict, need merging, etc.) with set A. The 
+idea is to allow a user to take two datasets, A and B, and generate a
+changeset from them such that the changeset includes all of the data in
+set B that does not overlap (conflict, need merging, etc.) with set A. The
 changeset can then be applied directly to dataset A, without generating any
 review items.
 
-This algorithm is still under development. Currently it works best if you use 
+This algorithm is still under development. Currently it works best if you use
 the Network Conflation conflicts matcher (see +conf/core/NetworkAlgorithm.conf+),
 but if you are in a situation where you need to process a lot of data quickly,
 using the unifying-conflation HighwayMatchCreator produces acceptable results,
@@ -20,38 +20,38 @@ isn't limited to roads: it will use any matcher specified in hootenanny when
 doing the conflation. Thus, waterways, railways, powerlines, POIs, areas, etc.
 will be included in the conflation operation.
 
-To re-iterated, hootenanny will consider any conflatable feature type during 
-differential conflation. Types that cannot be conflated by hootenanny (that 
-is, types for which hootenanny does not have a matcher) will be removed from 
-the differential output. This is to prevent possible duplication of features 
+To re-iterated, hootenanny will consider any conflatable feature type during
+differential conflation. Types that cannot be conflated by hootenanny (that
+is, types for which hootenanny does not have a matcher) will be removed from
+the differential output. This is to prevent possible duplication of features
 when differential conflation is used in an automated fashion to bulk-process
 data.
 
-In a nutshell, the basic differential algorithm works like this: both inputs 
-are loaded into a single map, with elements marked "unknown1" and "unknown2", 
-respectively. Matches are generated using all specified matchers, then all 
-of the elements involved in the matches are removed from the map. Next, all 
+In a nutshell, the basic differential algorithm works like this: both inputs
+are loaded into a single map, with elements marked "unknown1" and "unknown2",
+respectively. Matches are generated using all specified matchers, then all
+of the elements involved in the matches are removed from the map. Next, all
 of the remaining elements from the first input ("unknown1") are removed. At
 this point, the only elements remaining in the map will be elements from the
 second input that did not match any elements in the first input.
 
-So now we have all of the "new" geometry from the second input isolated as 
+So now we have all of the "new" geometry from the second input isolated as
 output, but what if there were also new or updated tags on some of the
 elements in the second input? How can we capture those new tags? If the
 --include-tags option is enabled, we simply go back through the matches
-derived in the previous step, and compare the tags of the elements involved 
-in the match. If the element from the second input contains new tag keys, or 
+derived in the previous step, and compare the tags of the elements involved
+in the match. If the element from the second input contains new tag keys, or
 tag values different from the first input element, the tags are merged using
-an overwrite algorithm, where all key/value pairs are kept from the first 
+an overwrite algorithm, where all key/value pairs are kept from the first
 input, all key/value pairs from the second input are appended, and any keys
 that conflict are assigned the value from the second input, as it is assumed
-that the second input contains updated information. The merged tag set is 
-applied to the *original* element geometry, and it is written out as a 
+that the second input contains updated information. The merged tag set is
+applied to the *original* element geometry, and it is written out as a
 changeset "modify" directive.
 
-In the future, it might be a good idea to detect coincident ways between the 
-input maps, and attempt to split them at overlapping endpoints. That is to 
-say, if way1 from map1 is coincident with way2 from map2, but way1 is 
-shorter - it might be a good idea to split way2 at approximately the endpoint 
+In the future, it might be a good idea to detect coincident ways between the
+input maps, and attempt to split them at overlapping endpoints. That is to
+say, if way1 from map1 is coincident with way2 from map2, but way1 is
+shorter - it might be a good idea to split way2 at approximately the endpoint
 of way1, thus allowing the "extra stuff" from way2 to make it into the output
 map.