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
_______________________________________________
Talk-us mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-us
