Re: [OSM-dev] Moving to stricter multipolygon parsing
+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 penor...@mac.com wrote: Osm2pgsql currently tries *very* hard to turn multipolygon relations into geometries. It currently detects two types of MP relations, new-style and old-style. A new-style MP has tags on the relation while an old-style MP only has type=multipolygon on the relation and relies on the ways for the tags. It then tries to deal with odd tagging in various ways. MP handling is one of the biggest sources of osm2pgsql bug reports[1] and a big time-sink. One of the bigger issues is moving tags from ways to MPs that are falsely detected as old-style. This is an attempt to interpret flawed tagging. 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. Osm2pgsql is not just a consumer of data, it is one of the main feedback tools, so it is strongly integrated into the feedback cycle, so if osm2pgsql doesn't process a multipolygon, a mapper will likely correct the tagging. By doing this, it will make it easier for those interpreting raw OSM data. 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, while 2.3k have two sets of tags among the ways. About 180 have three or more.[3] An old-style MP without entirely consistent tags on outers is ambiguous and in error. [1]: https://github.com/openstreetmap/osm2pgsql/search?q=multipolygontype=Issues [2]: A deleted tag is one such as source that osm2pgsql is dropping [3]: https://gist.github.com/pnorman/ebd41f5a1759916a48b5 ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Moving to stricter multipolygon parsing
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. ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Moving to stricter multipolygon parsing
+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 relations. regards Peter Am 13.06.2014 01:25, schrieb Paul Norman: Osm2pgsql currently tries *very* hard to turn multipolygon relations into geometries. It currently detects two types of MP relations, new-style and old-style. A new-style MP has tags on the relation while an old-style MP only has type=multipolygon on the relation and relies on the ways for the tags. It then tries to deal with odd tagging in various ways. MP handling is one of the biggest sources of osm2pgsql bug reports[1] and a big time-sink. One of the bigger issues is moving tags from ways to MPs that are falsely detected as old-style. This is an attempt to interpret flawed tagging. 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. Osm2pgsql is not just a consumer of data, it is one of the main feedback tools, so it is strongly integrated into the feedback cycle, so if osm2pgsql doesn't process a multipolygon, a mapper will likely correct the tagging. By doing this, it will make it easier for those interpreting raw OSM data. 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, while 2.3k have two sets of tags among the ways. About 180 have three or more.[3] An old-style MP without entirely consistent tags on outers is ambiguous and in error. [1]: https://github.com/openstreetmap/osm2pgsql/search?q=multipolygontype=Issues [2]: A deleted tag is one such as source that osm2pgsql is dropping [3]: https://gist.github.com/pnorman/ebd41f5a1759916a48b5 ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Moving to stricter multipolygon parsing
+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. 2014-06-13 2:25 GMT+03:00 Paul Norman penor...@mac.com: Osm2pgsql currently tries *very* hard to turn multipolygon relations into geometries. It currently detects two types of MP relations, new-style and old-style. A new-style MP has tags on the relation while an old-style MP only has type=multipolygon on the relation and relies on the ways for the tags. It then tries to deal with odd tagging in various ways. MP handling is one of the biggest sources of osm2pgsql bug reports[1] and a big time-sink. One of the bigger issues is moving tags from ways to MPs that are falsely detected as old-style. This is an attempt to interpret flawed tagging. 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. Osm2pgsql is not just a consumer of data, it is one of the main feedback tools, so it is strongly integrated into the feedback cycle, so if osm2pgsql doesn't process a multipolygon, a mapper will likely correct the tagging. By doing this, it will make it easier for those interpreting raw OSM data. 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, while 2.3k have two sets of tags among the ways. About 180 have three or more.[3] An old-style MP without entirely consistent tags on outers is ambiguous and in error. [1]: https://github.com/openstreetmap/osm2pgsql/search?q=multipolygontype=Issues [2]: A deleted tag is one such as source that osm2pgsql is dropping [3]: https://gist.github.com/pnorman/ebd41f5a1759916a48b5 ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev -- Darafei Komяpa Praliaskouski OSM BY Team - http://openstreetmap.by/ xmpp:m...@komzpa.net mailto:m...@komzpa.net ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Moving to stricter multipolygon parsing
2014-06-13 1:25 GMT+02:00 Paul Norman penor...@mac.com: 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 where I abuse the fuzziness of the old style: urban squares. While you often can't walk on all of their surface (e.g. there might be a fountain, a sculpture, buildings, green, etc. to exclude from highway pedestrian) the name will usually be for all of it. Adding only a name also doesn't solve it, because then it is not clear which kind of name it is (typology). This isn't really solved with old style MPs neither, of course, but at least this is less obvious and might be interpreted correctly by a human ;-) ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Moving to stricter multipolygon parsing
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, while 2.3k have two sets of tags among the ways. About 180 have three or more.[3] An old-style MP without entirely consistent tags on outers is ambiguous and in error. To support this change it would be nice to setup a list on the web with the buggy relations. A few ten thousands broken Wikipedia tags were corrected with such a list. Perhaps the change could be enforced later, after a lot of MPs are corrected. -- regards Holger ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Moving to stricter multipolygon parsing
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 mailgm...@katur.de wrote: 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, while 2.3k have two sets of tags among the ways. About 180 have three or more.[3] An old-style MP without entirely consistent tags on outers is ambiguous and in error. To support this change it would be nice to setup a list on the web with the buggy relations. A few ten thousands broken Wikipedia tags were corrected with such a list. Perhaps the change could be enforced later, after a lot of MPs are corrected. -- regards Holger ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Moving to stricter multipolygon parsing
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 already?) osm2pgsql write a list of conflicts as it encounters them? Cheers, Andy ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Moving to stricter multipolygon parsing
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. 2. If not, are there instructions we could do to OSM editors? If so, then perhaps this would be a good Advanced MapRoulette challenge. Most of the MR challenges are for beginners, but this might be a nice one for our more advanced user community. For the incorrect ones, yes. I've built a list of ones with 3+ distinct sets of tags. http://paulnorman.ca/files/3_plus.txt I'll fix formatting in a bit, but there's 222 relations there. The other column is the number of distinct. ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Moving to stricter multipolygon parsing
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 interpretation is, and IMHO it's the most intuitive interpretation, that the multipolygon relation describes it's own geometry, by referring to other objects (!) geometries, where these other objects may be features on their own or not. That means: Tags that are used on an outer closed way of a multipolygon relation should hold for the area enclosed by that way. Tags that are used on an outer non-closed way of a multipolygon relation should hold for that way, which is not closed and doesn't get more closed by other ways somehow related to it by a multipolygon. For inner member ways it's basically the same. This should IMHO not be dependent on any kind of tags (besides the area=yes for closed ways where the closedness is not clearly implied by other tags). regards Peter Am 13.06.2014 16:10, schrieb Martin Koppenhoefer: 2014-06-13 1:25 GMT+02:00 Paul Norman penor...@mac.com: 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 where I abuse the fuzziness of the old style: urban squares. While you often can't walk on all of their surface (e.g. there might be a fountain, a sculpture, buildings, green, etc. to exclude from highway pedestrian) the name will usually be for all of it. Adding only a name also doesn't solve it, because then it is not clear which kind of name it is (typology). This isn't really solved with old style MPs neither, of course, but at least this is less obvious and might be interpreted correctly by a human ;-) ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[josm-dev] Network File Access in JOSM
Hello, I am new to Linux, now using Ubuntu. Can you advise how I can open an *.osm file sitting at smb://server/share/osmdata/mypoints.osm When I use the Open File dialog I cannot see a network link, and placing the absolute link in the file name field doesn't work. -- Alex ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Network File Access in JOSM
Filesystems mounted like that only show up in Nautilus. They are handled in the background by the virtual filesystem stuff. To get it to show up to non-Gnome applications, you'd have to actually mount it. sudo apt-get install cifs-utils mkdir $HOME/server sudo mount -t //server/share $HOME/server You'll have to remount it after you reboot unless you create an entry in /etc/fstab that does it automatically. Eric On Fri, Jun 13, 2014 at 5:30 AM, Alex Rollin alex.rol...@gmail.com wrote: Hello, I am new to Linux, now using Ubuntu. Can you advise how I can open an *.osm file sitting at smb://server/share/osmdata/mypoints.osm When I use the Open File dialog I cannot see a network link, and placing the absolute link in the file name field doesn't work. -- Alex ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev -- Eric Ladner ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
