[OSM-dev] Nested relations and generic implementation of geometry constructs - Was :osm2pgsql patch for nested relations
sly (sylvain letuffe)
liste at letuffe.org
Thu Mar 1 14:26:20 GMT 2012
> 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
Unfortunelty, that problems comes from what's in the database and the fact
that several relation proposals exists with different meannings and different
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
The question is how do we improve that, while keeping free tagging system ?
We are having a discussion about type=waterway relation here :
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
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
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)
qui suis-je : http://sly.letuffe.org
email perso : sylvain chez letuffe un point org
More information about the dev