[OSM-dev] Nested relations and generic implementation of geometry constructs - Was :osm2pgsql patch for nested relations

Jochen Topf jochen at remote.org
Sat Mar 3 09:27:27 GMT 2012

On Fri, Mar 02, 2012 at 06:15:40PM +0100, sly (sylvain letuffe) wrote:
> Let's see what exists :
> type=multipolygon --> build-polygon (but waterway=riverbank and some lakes are 
> constructed with touching outer rings loosing the true geometry, if proper 
> processing is needed we whould need special tweaks of those cases)
> type=multipolygon are note expressly said to allow nested relations
> type=boundary --> almost build-polygon, but some members sneaked their way as 
> subareas while not part of the geometry and roles are different.
> In those there are cases where nested relation are forming the geometry

type=boundary is much the same as type=multipolygon. I have always argued that
only type=multipolygon should be used for boundary=administrative. One down.

> type=site (relation become categories ?)--> build-polygon but only for members 
> with role=perimeter and tags are pushed down

Postprocessing very much depends on what you want to do with those.

> type=route  --> build-linestring but only one route/(blank), and conditionnal 
> on those backward/forward/north/south/east/west

Routes are difficult. Depends on what you are doing. Just drawing colored lines
are relatively easy. But doing more needs much more sophisticated handling.

> type=waterway  --> build-graph special to handle the main stream and the side 
> streams to build a graph and not a linestring (special handling at GIS side 
> because it doesn't exist as valid WKT)

Never heard of those. There are only about 3500 cases in the database and no
documentation in the wiki. Another one down.

> type=street/associatedStreet --> build-linestring with role conditions

This is used rarely. Just get rid of it and use normal addr:* tags instead.
Another one down.

> There are others, but each might need some special roles conditions and the 
> way tags apply to what might be kind of special
> > The goal should be reducing the number of algorithms and re-using them 
> > as much as possible.
> I understand the goal, but fear that it won't be so easy

No, its not easy. But not because there are so many different types of
relations. I currently only see "multipolygon", "route", and "restriction" as
major players here.  It is difficult because a) we don't have good guidelines
on how to tag these things, which leads to b) people do all sorts of crazy
tagging. And c) processing those things depends on what you actually want to do
with them.

Boundaries, bodies of water, sites, are only different forms of areas really
and we should move towards a model where they can be expressed as proper areas
and until then use type=multipolygon.

There are different details on how public transport routes, hiking trails etc.
are handled, but it all comes down to an ordered list of ways.

And turn restrictions are a whole different thing alltogether.

Jochen Topf  jochen at remote.org  http://www.remote.org/jochen/  +49-721-388298

More information about the dev mailing list