[OSM-dev] Relation - Multipolygon = "Area"

Ben Supnik bsupnik at xsquawkbox.net
Tue Apr 19 18:27:58 BST 2011


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



More information about the dev mailing list