> 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 _______________________________________________ dev mailing list [email protected] http://lists.openstreetmap.org/listinfo/dev
