Re: [OSM-dev] Moving to stricter multipolygon parsing

2014-06-13 Thread Peter Wendorff
IMHO, and that's what most bothers me at the old interpretation of multipolygons, any tag that belongs to a closed way should be valid for that closed way. We don't inherit names from streets to bus route relations - why should we do so for names of polygons to multipolygons? Therefore my interpre

Re: [OSM-dev] Moving to stricter multipolygon parsing

2014-06-13 Thread Paul Norman
On 2014-06-13 8:17 AM, Serge Wroclawski wrote: Paul, I don't have anything technical to add but I have a suggestion or two: 1. If this is an area where the old multipolygons could be converted entirely to the new style- do you propose an automated edit to OSM? No. There's .25M of them or so.

Re: [OSM-dev] Moving to stricter multipolygon parsing

2014-06-13 Thread Serge Wroclawski
Paul, I don't have anything technical to add but I have a suggestion or two: 1. If this is an area where the old multipolygons could be converted entirely to the new style- do you propose an automated edit to OSM? 2. If not, are there instructions we could do to OSM editors? If so, then perhaps

Re: [OSM-dev] Moving to stricter multipolygon parsing

2014-06-13 Thread SomeoneElse
Holger Jeromin wrote: To support this change it would be nice to setup a list on the web with the buggy relations. (apologies for asking what might be the bleeding obvious but) Do any of the existing QA tools flag multipolygon outers with conflicting tags? Alternatively, could (or does it a

Re: [OSM-dev] Moving to stricter multipolygon parsing

2014-06-13 Thread Yves
Thing is, it may be easier to find a consensus in -dev than elsewhere. So a fixing list would be a good thing, indeed. Yves On 13 juin 2014 16:20:09 UTC+02:00, Holger Jeromin wrote: >Paul Norman schrieb am 13.06.2014 01:25: > >> To support this, I looked for some numbers. Using a shortened delete

Re: [OSM-dev] Moving to stricter multipolygon parsing

2014-06-13 Thread Holger Jeromin
Paul Norman schrieb am 13.06.2014 01:25: > To support this, I looked for some numbers. Using a shortened deleted tags > list, there are 1 million new-style and 261k old-style MPs. Of the > old-style, > 256k have a member with role outer. 251k of these have entirely consistent > tags on outers, wh

Re: [OSM-dev] Moving to stricter multipolygon parsing

2014-06-13 Thread Martin Koppenhoefer
2014-06-13 1:25 GMT+02:00 Paul Norman : > I think we need to move to a more strict parsing of MPs, accepting only > new-style MPs and old-style MPs where all outers have identical > non-deleted[2] > tags and the relation itself has no non-deleted tags. > +1 There is really only one usecase wher

Re: [OSM-dev] Moving to stricter multipolygon parsing

2014-06-13 Thread Komяpa
+1, spent a lot of time debugging issues when a tag from outer leaks into multipolygon itself. Also, I'd prefer to use not non-deleted tags, but the whole set of tags, as I'm currently using a stlyesheet with a large deletion list. This would make geometry interpretation stylesheet-independent. 2

Re: [OSM-dev] Moving to stricter multipolygon parsing

2014-06-13 Thread Peter Wendorff
+10 if we could enforce the strict usage in multipolygon relations this might as well be a step forward to a future area datatype as it would straighten the definition of how areas are defined currently, and start by a less ambiguous definition for the subset of areas described by multipolygon rela

Re: [OSM-dev] Moving to stricter multipolygon parsing

2014-06-13 Thread Malcolm Herring
Of course, what is really needed is an "area" primitive type that incorporates the generic multipolygon structure. Then editing tools would always generate the correct tagging. Relations would then be left to describe associations between objects and not geometries as well. _

Re: [OSM-dev] Moving to stricter multipolygon parsing

2014-06-13 Thread Yves
+1 for consistency MP would be easier to learn from example if a single method 'works'. Yves On 13 juin 2014 01:25:42 UTC+02:00, Paul Norman wrote: >Osm2pgsql currently tries *very* hard to turn multipolygon relations >into >geometries. It currently detects two types of MP relations, new-style >a