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

[sly (sylvain letuffe)]

> I know that there are precedents, but I am highly averse to coding 
> specific relation types into osm2pgsql.

So do I, as you mentionned below, the problem is not osm2pgsql specific, but 
will need work in every tool to maintain support for ever changing relation's 
way of tagging, and every new relation types making it hard to have generic 
processing. 

Unfortunelty, that problems comes from what's in the database and the fact 
that several relation proposals exists with different meannings and different 
tagging structures.

By "meannings" I mean that some relations are made to build a bigger geometry 
(type=multipolygon is one), some to records facts unreleated to geometry (i.e 
type=restriction )

The question is how do we improve that, while keeping free tagging system ?
 
We are having a discussion about type=waterway relation here :
http://wiki.openstreetmap.org/wiki/Talk:Relations/Proposed/Waterway
in the generic vs specific relation constructs.

Those favoring specific relation tagging have raised valid concerns about how 
hard it will be for mappers to enter nested relations and/or generic geometry 
building relations.

But as a data consumer and algorithm maker, it might become a nightmare to 
support all types of roles and logic behind those.

> one is pushing the geometry 
> up, the other is pushing the tags down.

I guess both would be needed depending on what was the purpose of the 
relation.
When the parent relation doesn't describe a geomety, but is a way to factor 
tags (name, ref, ...) maybe we need to push the tags down.
When the parent relation makes a big geometry made of several child relation 
having a part of the geometry, that's the opposite. (country boundaries made 
of several linear boundaries comes to mind type=boundary_segment)
 




-- 
sly
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org