Hi Igor,
Ah - now I get it. I would call these features perhaps "implicit
features", and I agree that it's important not to try to make too much
be explicit. The degenerate case would be creating a relation for the
result of every possible spatial DB query. :-)
At the same time, when it comes to spatial and geometric analysis,
sometimes having a little bit more spelled out makes a big difference to
clients, and in some cases I would suggest it might help data quality.
(E.g. explicit syntax might be a good foundation for error checking, etc.)
One of the ideas that gets tossed around periodically is the super-way,
that is, a group of ways that form one big 'thing'. These proposals
often cause concern to me, because they change the fundamental way that
all other tags are interpreted. I can (and do) ignore route relations,
but if a super-way relation came about, I would _have_ to support it or
risk grossly misinterpreting the tags. (For my straw man I am going for
a super-way that can host tags that apply to all sub-ways once.)
So here's my straw man: I would say we need support in the form of a new
primitive when...
- The spatial meaning of a primitive is ambiguous without deeply
interpreting tags. (This is the case I think a lot of us are frustrated
by, namely is it a closed way or an area.)
- A sane 'bounding box' of a relation isn't well defined without
understanding the tags.
Here's an example of the second: the turn restriction relation
references two ways, but it 'refers' to the way they connect to each
other. If our two ways intersect an area, but the turn happens 'far way
from us', we don't care...but if a relation's bounding box is the sum of
its parts, we pick it up anyway. By comparison, a bus route's bounds
would be the sum of its parts.
So this is my straw man ...
- Areas need to be moved out into their own primitive - that was the
original discussion topic, and I don't think I've seen anyone come
forward and go "no, closed ways and the multipolygon relation are better
than all other proposals."
- IF there is ever to be an intentional set of compositing primtives
(super-ways, super-areas, etc.) it should be down at the syntax level
where it can't be ignored, since the syntax would potentially affect
everything. (That is, a super-way that isn't allowed in every case that
a way is around strikes me as a mess.)
On the other hand, you could have such semantics specified in the DB as
a relation, one example are bus routes. But there you still need some
external knowledge on how to handle various roles of this type of a
relation.
Right..the existence of 'roles' pretty much guarantees that a relation
requires interpretation.
But I do feel that the area as an OSM primitive is badly needed. Here
even _with_ external semantics it is sometimes difficult to determine
whether an OSM way represents a polyline or a closed polygon.
Agreed 100%. :-) If we end up with a real area primitive and nothing
else happens regarding compositing, etc. I'd still be a happy camper.
cheers
ben
--
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
