Re: [OSM-dev] Nested relations and generic implementation of geometry constructs - Was :osm2pgsql patch for nested relations
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. I do agree with you on the fact that boundaries could or should be tagged as type=multipolygon, but that is not the case in the database. More than that, there are members with role=subarea in it making them no more a geometry valid as defined by type=multipolygon 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. wiki page is here : http://wiki.openstreetmap.org/wiki/Relations/Proposed/Waterway -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Nested relations and generic implementation of geometry constructs - Was :osm2pgsql patch for nested relations
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 -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Nested relations and generic implementation of geometry constructs - Was :osm2pgsql patch for nested relations
Am 01.03.2012 15:26, schrieb sly (sylvain letuffe): 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 ? By defining algorithms to work with relations in one place and mapping relation-types to that algorithms in another place. For example: type=multipolygon -- build-polygon type=route-- build-linestring type=waterway -- build-polygon type=restriction -- discard type=windmils -- collect The goal should be reducing the number of algorithms and re-using them as much as possible. Peter ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Nested relations and generic implementation of geometry constructs - Was :osm2pgsql patch for nested relations
On 2 March 2012 12:44, Peter Körner osm-li...@mazdermind.de wrote: type=route -- build-linestring Remember that there's more than one way to process a route relation - you can either duplicate the underlying geometries, one per relation, or push information from the relation down onto the existing geometry, and perhaps concatenate values. But otherwise, your idea of building a list of algorithms is a good one, and lends itself well to configuration files. There's so much stuff baked into osm2pgsql that should really be configurable. Cheers, Andy ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Nested relations and generic implementation of geometry constructs - Was :osm2pgsql patch for nested relations
On vendredi 2 mars 2012, Peter Körner wrote: By defining algorithms to work with relations in one place and mapping relation-types to that algorithms in another place. The idea looks sexy, but relations have so many different construction that you will probably end with as much algorithms as there are relation types. For example: 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=site (relation become categories ?)-- build-polygon but only for members with role=perimeter and tags are pushed down type=route -- build-linestring but only one route/(blank), and conditionnal on those backward/forward/north/south/east/west 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) type=street/associatedStreet -- build-linestring with role conditions 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 -- sly qui suis-je : http://sly.letuffe.org email perso : sylvain chez letuffe un point org ___ dev mailing list dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Nested relations and generic implementation of geometry constructs - Was :osm2pgsql patch for nested relations
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 dev@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev
