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, low-risk change. 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. Wiki: https://wiki.openstreetmap.org/wiki/User:Ekidd/Coastal_Maine_problems County: https://www.openstreetmap.org/changeset/26104709#map=8/44.090/-68.730 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 review.) -Eric 2014-10-15 14:25 GMT-04:00 Peter Dobratz <pe...@dobratz.us>: > > > On Wed, Oct 15, 2014 at 9:33 AM, Eric Kidd <emk.li...@randomhacks.net> > wrote: > >> 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 > government. > > 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. > > --Peter > >
_______________________________________________ Talk-us mailing list Talk-us@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-us
