[Talk-us] Coastal Maine needs love
emk.lists at randomhacks.net
Wed Oct 15 21:09:26 UTC 2014
Thank you, everybody, for your advice. Special thanks to Peter for his
experience with similar issues in New Hampshire.
Earlier today, I added 4 towns on the Boothbay peninsula, which was a nice,
Just a moment ago, I updated the southern half of Lincoln county with the
TIGER 2014 county data, splicing it into Sagadahoc and Knox counties on
either side. This is a pretty big change, and I was as careful as I could
be, but I'd appreciate another set of eyes.
Everything was done with boundary lines and relations, and I cleared up all
JOSM validation errors on the parts I touched.
Overall, this sort of cleanup seems like it would help coastal Maine a lot.
The maps are a lot nicer looking, and Nominatim is working now. That only
needs 7 counties that are in need of love. :-) (And one which is in need of
2014-10-15 14:25 GMT-04:00 Peter Dobratz <peter at dobratz.us>:
> On Wed, Oct 15, 2014 at 9:33 AM, Eric Kidd <emk.lists at randomhacks.net>
>> Thank you for your response!
>> I've made two test edits:
>> - I imported TIGER County Subdivision files for four town boundaries.
>> - I modified an existing TIGER Place outline to be admin_level=9,
>> because it's a actually a subdivision of the real town. That's the brown
>> blob on my example map.
>> I think you are on the right track with the TIGER County Subdivision
> files. I did a lot of work on the town boundaries in New Hampshire and it
> probably had the same sort of mess you are seeing in Maine. Boundaries for
> towns were imported multiple times by different users and the county
> boundaries were imported using a much lower precision source. At least in
> New Hampshire, the county boundaries are most often coincident with town
> boundaries, so it makes sense to have these in OSM as Relations (not as
> closed Way polygons) and sharing the Way objects among multiple
> boundaries. Also, the TIGER CDP shapes were erroneously used in place of
> the actual town boundaries. The CDP for a town is often generally where
> the most of the people live, but the actual boundary for the town is a much
> larger area and this can be verified against town-line signs on the ground.
> The TIGER boundary data seems to want to share nodes with TIGER road data
> even though it doesn't actually make sense. For example, town boundaries
> are often straight lines, but in TIGER these lines are slightly jagged so
> that they can share points with roads that are close to the town line. If
> you look at resources like property tax maps that some towns make
> available, you can see that in many cases the TIGER boundary data should
> just be made into straight lines. And straight lines in OSM should just be
> represented by a Way connecting 2 Nodes (your simplify step in QGIS will
> get you most of the way there).
> Tagging on the Ways is completely optional as that information should all
> be in the admin Relations. However, the consensus is that the Ways should
> have the admin_level be the lowest number (for example admin_level=6 for
> Ways that make up both a town and a county boundary) rather than trying to
> have multiple values separated by semicolons.
> Generally, I have used admin_level=9 for areas inside of towns that appear
> to be separately administered. In some larger towns, I used admin_level=9
> for the wards or districts which correspond to seats on the local
> Towns have also been imported as single nodes, which could be influencing
> your Nominatim results. These place Nodes should be added to you admin
> Relations with role "admin_centre" or "label". You should also add
> wikipedia tags to the boundary relations as this will help Nominatim
> determine the place hierarchy.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Talk-us