Hi Josef,
Slight aside...your questions about "is this really allowed" mirror my
thinking when I first started working with OSM data for X-Plane.
The very question "is X permitted" is a somewhat problematic one for
OSM. I would almost compare it to the question "are misspelled words
allowed on Wikipedia"? I think the Wikipedia editing standards probably
frown on misspellings, but at any give time, between when a user
misspells a word and when another user fixes it, a snapshot of 'the
wiki' would reveal violations of the policy.
OSM takes this to the next level: not only is there the risk of 'policy'
being violated at any given time (e.g. there is no enforcement of policy
when a change is applied) but the very policy itself is a lot looser at
best. I don't know how much of this is culture (I have seen a share of
opinions on this list that the wiki isn't particularly authoritative),
how much is technical (the people 'spec'ing things on the wiki don't
always maintain the code, so you can write a spec for a super-way and
nothing will happen) and how much is process (since we have no
super-strong policies, client code takes a fuzzy approach to data, which
makes policy less important, repeat loop) but...either way, you can't
really view the wiki as a definitive guide to the data.
So...if you want to actually _use_ the data, what can you do? Once you
clear your mind of old-school GIS-like ideas, things will be easier. :-)
In X-Plane's case, we...
1. Attempt to align our interpretation of the data as much with the maps
as possible. That is, if data seems broken in the .osm file but the
maps render it, I figure I need to figure out their fall-back case and
implement it, so that my users don't have to worry about cleaning data
in ways they can't see and fix.
2. Process the data with a really robust set of tools, so that we don't
depend on any geometric properties of the data. We use CGAL, which
provides robust polygon cutting under pretty much any conditions, no
floating point limits to worry about. We explicitly check for
degeneracies and decide how to handle them (e.g. what if a polygon is
self-intersecting, empty, holes go through the outer boundary, etc.).
3. We sanity check the incoming data. This is fairly specific to our
app case and may not be appropriate for others. If a way goes straight
up a mountain at a 80 degree slope and its type is motorway=trunk, we
throw it out. It's much more likely that there's a conflict between our
elevation data and the road than that there's a road going up at that
slope, and frankly it's going to look stupid in X-Plane anyway. So we
protect ourselves from data problems by being more committed to
'plausibility' than 'accuracy'.
But...a few rays of hope in all this...
- A traditional GIS db might tell you the problems, but it will _still_
have a ton of problems. (Heck, try VMAP0, it'll have problems they
declare and problems they let you discover. :-)
- In practice, the value proposition of OSM makes it worth it. The data
quality and coverage world-wide is pretty unprecedented...
I'm not sure if that answered your question, but hopefully it sheds some
light on why there aren't really good answers to your questions.
cheers
ben
On 4/20/11 12:11 AM, [email protected] wrote:
A simple question:
Can someone point me to an explanation/discussion about whether overlapping
polygons are 'permitted' or not? I get a different answer every place I look,
and I need to get this question out of the way before before I can even
consider developing with OSM.
Cheers,
Josef.
_______________________________________________
dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/dev
--
Scenery Home Page: http://scenery.x-plane.com/
Scenery blog: http://www.x-plane.com/blog/
Plugin SDK: http://www.xsquawkbox.net/xpsdk/
X-Plane Wiki: http://wiki.x-plane.com/
Scenery mailing list: [email protected]
Developer mailing list: [email protected]
_______________________________________________
dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/dev
