[Talk-us] Admin borders in the US

[stevea]

>On 11/3/13 12:17 PM, Martijn van Exel wrote:
>>  Administrative boundaries are generally not verifiable by ground
>>  surveying, and are not straightforward to edit. This causes
>>  information rot. What good is administrative boundary information that
>>  are not trustworthy? Moreover, they are freely[1] and easily available
>>  from an authoritative source. For all these reasons combined, I would
>>  favor them not being in OSM at all.
>>
>on the other hand, people expect to see at least some of these
>boundaries in a map, and apps like Nominatum and various
>GPS apps (OsmAnd being one) use them.
>
>i understand your point of view, but removing them will be
>very disruptive to a bunch of important data consumers.
>
>what i favor is going to a multi layer approach where some
>layers of OSM are ground verifiable things and others may
>not be. a consumer could choose to use some layers, and
>the admin boundaries (which are a real problem) can be
>moved and we can consider how to approach them differently
>because what we're doing now isn't working real well.

A wonderful and broad topic.  Richard's multi layer approach is 
laudable.  A balance with legacy and syntax is to not be brittle and 
strict so as to strangle the future.  Sure, you can do so and rewrite 
in the future, either that or think ahead.  We use superrelations to 
describe semantic behavior (states and nations).  Tags and "how it 
might make sense to consume these data" are often wildly different, 
when you get right to it.  Political boundaries can be as fluid as 
flooded roads.  I believe OSM wants a modicum of political and 
boundary data, whether parks, open space, wilderness, forest, city 
limit, neighborhood, etc.  Data overlap like that is one thing that 
makes OSM so useful.  It now sings beautiful choruses, has a few sour 
notes here and there, and everything in between.  It tunes up here 
and now (and in a likeable way, if I say so myself).

See, teasing out "how the data are used" and "what the data are" 
(are, AND will be) truly are relevant.

CDPs are a wide weird animal.  We could go on and on.  In some cases 
they are better than nothing, in others they are noise and in still 
others they are better off left out or never entered.  This is an 
educated guess, but it seems when uploaded OSM data meet criteria of 
Basic Quality, they stay uploaded.  Maybe (we hope) they get updated 
with a new census or new TIGER or even new hydro data (OK hydro is 
much less a political animal being more landuse or natural), 
depending on the active local community of people saying "good enough 
for here."  Or, "we intend to update if and when we get better and/or 
newer data."  That's real, and a good sign in an OSM community when 
true.  Often, (and another good sign, as it shows intention of 
priority) there is a list of what's next and dream topics, and how 
"those" get started.  It's a conversation.

Let's identify (prioritize) problem areas, problem specifics, common 
tagging errors in the syntax that can be harmonized and maybe better 
ways to determine date of (original, imported, if they were) data 
published.  A much harder metric to start wanting to assign (but it 
could be proposed) is a quality or trust scale.  This might vary 
based on the consuming applications specific appetite (geocoding, 
neighborhood, quarter, suburb, town, village, hamlet, 
isolated_dwelling, whatever).  This way, data consumers have a hook 
to poll data selectively in a newer different way that should help 
their results.  OSM already IS multi layer in a few senses, might we 
sharpen up the focus of how we rate or trust data?  Like inventing a 
small tag syntax that largely captures good ways to describe (and 
hook) the now data, legacy consumers and the future?  A terrific 
solution, and it seems a worthy yet difficult thing to do (achieving 
agreement from wide asking, designing the language tags can be easy 
or difficult...).

This is especially useful as a large, wide goal is only over a longer 
term.  If I know I should tweak a legacy algorithm today like this, I 
would:  "reject CDPs from New York State."  But you need to know to 
do that.  How?  A serious power in OSM is its free-form tagging 
(language writing ability).  Data consumers who make sense out of 
many layers here, win.  Tag appropriately.  (And it goes without 
saying, upload appropriately).  Designing little tag languages of 
wide and harmonious consensus?  Which benefit data consumers and stay 
flexible for a future?  Ah.

Then again, there is nothing like a wonderful future where "many 
agree, OSM is awesome" is largely true.  We take steps, we build 
bridges, we get there.  (There may also be few, no or bad patterns to 
discern that well-crafted tag linguistics can help, though I hold out 
hope).

We keep meeting in the middle:  I like it!  Good conversation.

SteveA
California