Hi Y'all,
On 4/19/11 1:14 PM, Igor Brejc wrote:
> I'm more and
more convinced something better is needed: OSM primitives represent
parts of the higher-level features and should be treated as such. Examples:
* A collection of road ways represent a road graph/network. Graph
vertices are not necessarily the same as starting/ending way nodes
(BTW Maperitive already works this way).
* A collection of riverbank areas represent a single multipolygon
element.
* Various bus route relations represent a _single_ network of bus
routes. A graph edge can represent one or more bus routes.
It seems like there are a lot of different 'composite' problems going on
-- I'm not even sure how to sort it out.
At a minimum, I would draw a distinction between:
1. Compositing as optimization, that is, a subdivided area for the
purpose of OSM restrictions (E.g. a large area cut into two smaller
areas to overcome maximum node count/area size/manageability, etc. In
these cases, we might want to think about compositing things together to
explicitly get a handle on 'tiling' problems.
(My 'area of areas' proposal on the wiki, which I should say is I think
not a very good proposal and is just there for completeness, attempts to
address this by allowing an area of areas...it is expected that the
larger "super-area" is "the entity".)
2. Compositing to make truly strange spacial shapes. For example,
compositing several ways into a network where the entity has the extent
of the entire network, or compositing a way and an area into a
combined...um...thingie.
3. Compositing related distinct entities into a larger entity, e.g. what
we can sort of do with relations now.
The difference between case 2 and 3 may not be very clear...heck, there
may not even be a distinction. My argument from earlier today is that
you should be able to know the location of an element in OSM without
having to interpret the tags...that is, the spatial aspects of OSM
should be syntax, not semantics. (We are _mostly_ there now.)
So case 2 would be related elements that form a bigger super-spatial
thing, while case 3 would be relations as we have them now (e.g. "if you
understand these tags, you might be able to piece together these parts.")
Hrm...I suppose I could say: case 2 would _not_ have roles, but case 3
would. (In case 2, the role of all parts of a composite is "sub-part".)
Of course, it may _still_ be up to the renderer to decide when to
connect vs. not connect areas...I think under my distinctions here, the
renderer would have discretion in case 3 to 'merge or not merge' but in
cases 1 and 2, the correct behavior would always be to treat the super
area as the area.
(This of course puts more work on clients to calculate correct
super-areas...)
cheers
Ben
_______________________________________________
dev mailing list
[email protected]
http://lists.openstreetmap.org/listinfo/dev
