<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Graeme Fitzpatrick:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">So when the road doesn't track between those boundaries on the map, what do we do? Move the road, move the boundaries, or say, it's not worth worrying too much about it?<br></div></div></blockquote><div><br></div><div>Do any of the inconsistent data sources have metadata that say at what map scale they should be interpreted?  You may simply be dealing with data that were digitized from an inappropriately small-scale map.  It happens.</div><div><br></div><div>Also, are both sources referenced to the same datum plane?  (Or worse, have geometries referenced to the wrong datum crept into the sources?)</div><div><br></div><div>If the metadata don't give any indication of the quality of the source (and the source isn't TIGER:  in my experience, when TIGER disagrees with anything else about geometry, TIGER's wrong!)  then at some point I say, "beyond my pay grade, let the respective agencies sort it out if they actually care."   </div><div><br></div><div>Minh Nguyễn:</div><div>> However, the lesson I draw is not that things shouldn't be connected to each other explicitly, but rather that mappers should be mindful about how existing data came to be. Even ignoring the issue of boundary alignment, there are many boundaries that don't make a ton of logical sense, so we have to be vigilant about mappers naïvely oversimplifying them.</div><div><br></div><div>Indeed!</div><div><br></div><div>In New York, I unglued the highways from the municipal boundaries because the TIGER import (or a mechanical edit to "fix" its duplicate nodes) had promiscuously glued the boundaries to everything nearby: not just roads and watercourses, but driveways, building corners, utility poles, pipelines, you name it.  They'd not been glued by any deliberate decision of a mapper. If a mapper makes the deliberate decision to reglue them because the metes and bounds are defined in terms of them, that's an improvement. </div><div><br></div><div>Given the mess that I found, it appeared to me that having the boundaries unglued was better than having everything fused together willy-nilly.  It was definitely an improvement for many municipal boundaries that were obviously following the edge of rights-of-way rather than the road center line;  when I see two village lines that appear to be precisely 22 yards (4 rods) apart with a roadway in between, that's a dead giveaway that both villages would rather have the township go to the trouble and expense of maintaining the road.  TIGER had a lot of these boundaries fused with the centerline.</div><div><br></div><div>I'm pretty sure that Preemption Road, which appears to follow multiple town lines, is supposed to be aligned with the historic Preemption Line, and so perhaps the boundaries ought to be fused, but I think that in doubtful cases, it's better to leave them separate.  I've seen a lot of "County Line Road" and "Town Line Road" that _mostly_ follow a boundary but occasionally stray from it.</div><div><br></div><div>Then again, New York has a handful of county and township lines that someone drew on a map in the 18th century and nobody has successfully surveyed.  Nor does anyone much care where the line is through places like the St. Regis Swamp or the Adirondack High Peaks - so nobody is likely to survey and monument it. When it becomes an issue, the courts sort it out. Gore Mountain is named because it was located in a surveyor's gore - in neither the township to the east nor the one to the west. Nobody cared until Barton found garnets there.  The municipalities were in court for years over who had the right to tax the mines.</div><div><br></div><div> Vermont and New Hampshire disagreed about the state line from 1764 to 1933. </div><div><br></div><div>Beyond my pay grade, indeed.<br></div><div><br></div></div>-- <br><div dir="ltr" class="gmail_signature">73 de ke9tv/2, Kevin</div></div>