[Talk-us] Coastal Maine needs love

Eric Kidd 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,
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 <peter at dobratz.us>:

>
>
> On Wed, Oct 15, 2014 at 9:33 AM, Eric Kidd <emk.lists at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-us/attachments/20141015/40afd5fe/attachment.html>


More information about the Talk-us mailing list