Re: [OSM-talk] osm2pgsql multipolygon parsing
2013/9/23 Kai Krueger kakrue...@gmail.com wrote: Indirectly it is a question of tagging schemas. To me this is actually indirectly a question of a proper area type! See e.g. Towards an Area Datatype for OSM from Jochen at SOTM http://lanyrd.com/2013/sotm/scpkrr/ --Stefan 2013/9/23 Kai Krueger kakrue...@gmail.com quot;Petr Morávek [Xificurk]quot;-2 wrote Anyway, this thread was not started to debate tagging schemes, the question I (and others) wanted to discuss here is this: Given the data that are currently in the database, how should osm2pgsql handle the import to get as much as possible multipolygons right? Indirectly it is a question of tagging schemas. With osm2pgsql being the tool used in the default map rendering on osm.org and the prevalence of tagging for the renderer decisions on how it handles multipolygons will (and imho to a limited degree should) influence how people tag and what they perceive as correct tagging. Therefore it is important that there is a consensus of what the correct tagging schema is and make sure that is correctly supported by osm2pgsql. That is also why I think having this discussion on talk, rather than on github or the dev list is appropriate. We need to come to a consensus between all of the main tools (at least iD, P2, JOSM, osm2pgsql, osrm, ...) and the mappers to what the preferred, encouraged and supported standard for tagging multi-polygons is and make sure that all documentation is in line with this. -- View this message in context: http://gis.19327.n5.nabble.com/osm2pgsql-multipolygon-parsing-tp5778300p5778654.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql multipolygon parsing
Am 24.09.2013 10:12, schrieb Stefan Keller: 2013/9/23 Kai Krueger kakrue...@gmail.com wrote: Indirectly it is a question of tagging schemas. To me this is actually indirectly a question of a proper area type! See e.g. Towards an Area Datatype for OSM from Jochen at SOTM http://lanyrd.com/2013/sotm/scpkrr/ +1 But the transition necessary is the same: IF we could come to a stable, but backwards compatible solution by step-by-step hardening the current multipolygons it would be easier to create a new area datatype later converting multipolygons on the fly. While it is NOT possible overall to convert ways to polygons later (as you would have to do that tag-based, and have to make sure to duplicate it if there are line-tags and area-tags on the same way and so on), it might be possible to auto-convert multipolygons to area; but to do that multipolygons have to be clearly defined and possible to handle. The discussion of this thread tackles the problem left for any such conversion in future: What is the area described by any given multipolygon with the given tags on inner/outer/relation? If we could come to a clear consensus about that, and if we could slowly enforce fixing any problems according to that in the data, then a conversion to a new area data type could be done with less errors and problems than it could be done now. But thanks for the area datatype argument, as it's an additional argument to strenghten the Multipolygon definition and -interpretation for the current (or very near future) osm. regards Peter --Stefan 2013/9/23 Kai Krueger kakrue...@gmail.com quot;Petr Morávek [Xificurk]quot;-2 wrote Anyway, this thread was not started to debate tagging schemes, the question I (and others) wanted to discuss here is this: Given the data that are currently in the database, how should osm2pgsql handle the import to get as much as possible multipolygons right? Indirectly it is a question of tagging schemas. With osm2pgsql being the tool used in the default map rendering on osm.org and the prevalence of tagging for the renderer decisions on how it handles multipolygons will (and imho to a limited degree should) influence how people tag and what they perceive as correct tagging. Therefore it is important that there is a consensus of what the correct tagging schema is and make sure that is correctly supported by osm2pgsql. That is also why I think having this discussion on talk, rather than on github or the dev list is appropriate. We need to come to a consensus between all of the main tools (at least iD, P2, JOSM, osm2pgsql, osrm, ...) and the mappers to what the preferred, encouraged and supported standard for tagging multi-polygons is and make sure that all documentation is in line with this. -- View this message in context: http://gis.19327.n5.nabble.com/osm2pgsql-multipolygon-parsing-tp5778300p5778654.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql multipolygon parsing
Am 23.09.2013 18:48, schrieb Yves: Sorry, I meant osm2pgsql is not used for the slippy map ONLY. Thanks for all the feedback :) Sure, but changing the DEFAULT behaviour to a more strict one while keeping the old behaviour with a flag should enable anybody to keep the old behaviour on demand; and whoever updates a software like this to a new version should read the release-notes to get this IMHO (or be patient if something changes). regards Peter ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql multipolygon parsing
On Sun, Sep 22, 2013 at 12:29 PM, Peter Wendorff wendo...@uni-paderborn.de wrote: The suggestion is to discourage this in all cases and encourage always tagging the relation (this is also straightforward and much easier as you can do A or B). +1 -1 Check cities with tens of thousands buildings. You will have sometime the building tag on ways, sometimes on relations. Having the tag always on the surrounding way is more consistent and easier to catch for everybody, including newcomers. Pieren ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql multipolygon parsing
2013/9/23 Pieren pier...@gmail.com -1 Check cities with tens of thousands buildings. You will have sometime the building tag on ways, sometimes on relations. Having the tag always on the surrounding way is more consistent and easier to catch for everybody, including newcomers. Not if they use iD. In iD multipolygons and areas are selected in the same way, by clicking in the building. Janko ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql multipolygon parsing
Am 23/set/2013 um 11:03 schrieb Pieren pier...@gmail.com: Check cities with tens of thousands buildings. You will have sometime the building tag on ways, sometimes on relations. Having the tag always on the surrounding way is more consistent and easier to catch for everybody, including newcomers. it has a different meaning. tags on a closed way are for the whole area inside the way, tags on a mp relation are for the area of the outer minus the inner ways. Where to put which tag depends on what you want to express. cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql multipolygon parsing
From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] Subject: Re: [OSM-talk] osm2pgsql multipolygon parsing it has a different meaning. tags on a closed way are for the whole area inside the way, tags on a mp relation are for the area of the outer minus the inner ways. Unless the closed way is a member of a multipolygon relation with no other tags on the relation - then you'll have a resulting area with a hole. This is a very well established means of tagging areas with holes (~22% of type=multipolygon relations have no other tags). The issues raised originally in the ticket are best explored through examples The first case is a way with natural=water and a MP relation with no other tags. Both old osm2pgsql (0.82) and latest master version from git create an area with a hole with natural=water on the area. There are no suggestions of changing this. The second is a way with natural=water and a MP relation with name=foo (with the way as a member). Old osm2pgsql created an area with a hole with natural=water, name=foo, latest master does too. The third is the second with the same as the 2nd, but a name:de tag added. In old osm2pgsql this created an area without a hole, in latest master it creates one with a hole. The fourth is a way with natural=water and a MP relation with foo=bar. In old osm2pgsql this created an area without a hole, in latest master it depends on the .style file used for import. To make #3 consistent with #2 without breaking backwards compatibility latest osm2pgsql doesn't use a pre-defined list of tags to differentiate between old-style and new-style MPs, it uses its list of tags that denote an area. The specific issue that brought this up is actually fixed by only bringing tags onto the MP area where all outer members have the tag, but there's still a more general question. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql multipolygon parsing
Am 23.09.2013 11:59, schrieb Paul Norman: From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] Subject: Re: [OSM-talk] osm2pgsql multipolygon parsing it has a different meaning. tags on a closed way are for the whole area inside the way, tags on a mp relation are for the area of the outer minus the inner ways. Unless the closed way is a member of a multipolygon relation with no other tags on the relation - then you'll have a resulting area with a hole. This is a very well established means of tagging areas with holes (~22% of type=multipolygon relations have no other tags). It's well established, but it's less correct from a theoretical point of view, and establishment is produced here by software that supports wrong tagging - in the past. You propose to leave it as it is, which means software should estimate the meaning because often there are errors in the tagging, while I proposed (and as far as I understand at least Martin supports that) not to ignore these errors with the goal to teach mappers about what's correct instead of teaching them what's correct enough for application X (be it the default mapnik style and -pipeline). The issues raised originally in the ticket are best explored through examples The first case is a way with natural=water and a MP relation with no other tags. Both old osm2pgsql (0.82) and latest master version from git create an area with a hole with natural=water on the area. There are no suggestions of changing this. Problem: Let's say the multipolygon relation was tagged before as depth=shallow (and someone wanted to mark parts of the water as not deep - e.g. not deep enough for boats). Let's say another mapper came along and found this strange tags and - removing them - accidently left a multipolygon without tags. This changes the meaning of stuff never touched again, as you would now count the natural=water only for the area covered by the multipolygon, excluding the hole. The second is a way with natural=water and a MP relation with name=foo (with the way as a member). Old osm2pgsql created an area with a hole with natural=water, name=foo, latest master does too. What if the inner part does NOT have that name, but only the outer ring? What if that is what somebody wanted to say? regards Peter ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql multipolygon parsing
Dne 23.9.2013 11:59, Paul Norman napsal(a): Unless the closed way is a member of a multipolygon relation with no other tags on the relation - then you'll have a resulting area with a hole. This is a very well established means of tagging areas with holes (~22% of type=multipolygon relations have no other tags). Yes, but if the relation has any[*] additional tags, you can't reliably decide what was the intended purpose of this tagging. Imho the only logical thing is to treat the relation and ways separately. [*] Maybe some internal keys could be ignored, e.g. odbl, fixme, ... The issues raised originally in the ticket are best explored through examples The first case is a way with natural=water and a MP relation with no other tags. Both old osm2pgsql (0.82) and latest master version from git create an area with a hole with natural=water on the area. There are no suggestions of changing this. Agreed. The second is a way with natural=water and a MP relation with name=foo (with the way as a member). Old osm2pgsql created an area with a hole with natural=water, name=foo, latest master does too. Is this really correct? In case of the name=foo it is probably safe assumption, but how about multipolygon relation with only access=* tag (or something similar)? How do you decide, if it means the area with holes is natural=water+access=*, or that the whole area (with no holes) is natural=water and only some parts have access=*? The fourth is a way with natural=water and a MP relation with foo=bar. In old osm2pgsql this created an area without a hole, in latest master it depends on the .style file used for import. The dependence on on the .style file bothers me, I think it's a mistake and will ultimately come back to haunt us. If you don't care about some features and delete the lines from your .style file, the multipolygon parsing should not change. -- I propose that: 1) By default the relation and ways are treated separately - relation creates polygon with tags from the relation and ways are processed on their own. 2) If and only if the relation has only type=multipolygon tag go to backward compatibility mode. Copy over tags from outer ways that are present on all of them and create polygon. Go over all member ways and if all their tags are present on the created polygon, then mark them as done, otherwise process them separately. -- I have looked at all the multipolygon relations that do not have any of the well-known polygon tags (the ones defined in default.style), this is less than 27% of all the multipolygon relations. 85% of these relations have type=multipolygon tag only, so the proposed change in fact affects less than 4% of all the multipolygons. More detailed breakdown of tags on multipolygons without well-known polygon tags: percentage keys 85.5% type 3.7%ref,type,id_ob,adr_les 1.7%type,name 1.5%area,type,highway Best regards, Petr Morávek aka Xificurk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql multipolygon parsing
Am 23.09.2013 15:20, schrieb Petr Morávek [Xificurk]: I propose that: 1) By default the relation and ways are treated separately - relation creates polygon with tags from the relation and ways are processed on their own. 2) If and only if the relation has only type=multipolygon tag go to backward compatibility mode. Copy over tags from outer ways that are present on all of them and create polygon. Go over all member ways and if all their tags are present on the created polygon, then mark them as done, otherwise process them separately. +0.75 ;) Agree, but I would use (2) if and only if backward compatibility mode is active. Additionally I would not use the backward compatibility mode for the mapnik default sheet (after some time with big announcements an probably a tool detecting/reporting possible problems for fixing). With this we could - enforce more correct tagging in future - engage the mappers community to fix where the bad-style tagging is used yet - gracefully allow any other application to fall back to the old style as long as they want to. This might (!) degrade the perceived quality of the default mapnik layer for some time (!), but IMHO it's worth it as it simplifies multipolygon interpretation and on the long term teaches mappers to use the tagging that is correct and matches that simplified interpretation. regards Peter ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql multipolygon parsing
Sorry, I meant osm2pgsql is not used for the slippy map ONLY. Thanks for all the feedback :) Yves -- Envoyé de mon téléphone Android avec K-9 Mail. Excusez la brièveté.___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql multipolygon parsing
Dne 23.9.2013 16:03, Peter Wendorff napsal(a): Am 23.09.2013 15:20, schrieb Petr Morávek [Xificurk]: I propose that: 1) By default the relation and ways are treated separately - relation creates polygon with tags from the relation and ways are processed on their own. 2) If and only if the relation has only type=multipolygon tag go to backward compatibility mode. Copy over tags from outer ways that are present on all of them and create polygon. Go over all member ways and if all their tags are present on the created polygon, then mark them as done, otherwise process them separately. +0.75 ;) Agree, but I would use (2) if and only if backward compatibility mode is active. Additionally I would not use the backward compatibility mode for the mapnik default sheet (after some time with big announcements an probably a tool detecting/reporting possible problems for fixing). With this we could - enforce more correct tagging in future - engage the mappers community to fix where the bad-style tagging is used yet - gracefully allow any other application to fall back to the old style as long as they want to. This might (!) degrade the perceived quality of the default mapnik layer for some time (!), but IMHO it's worth it as it simplifies multipolygon interpretation and on the long term teaches mappers to use the tagging that is correct and matches that simplified interpretation. regards Peter This is probably a good idea in the long-run, but there are things that need to be done before this cut-off and all of them need a certain transitional period. 1) You need to edit wiki and make people aware that this tagging scheme is considered deprecated. 2) You need to make sure, that all the editors produce correct multipolygon relations. 3) Fix the deprecated tagging on most of the elements. I really don't think it's a good idea to suddenly stop rendering quarter of the multipolygons out there just to enforce some thought-out policy... I don't see who would benefit from this. Anyway, this thread was not started to debate tagging schemes, the question I (and others) wanted to discuss here is this: Given the data that are currently in the database, how should osm2pgsql handle the import to get as much as possible multipolygons right? Best regards, Petr Morávek aka Xificurk ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql multipolygon parsing
quot;Petr Morávek [Xificurk]quot;-2 wrote Anyway, this thread was not started to debate tagging schemes, the question I (and others) wanted to discuss here is this: Given the data that are currently in the database, how should osm2pgsql handle the import to get as much as possible multipolygons right? Indirectly it is a question of tagging schemas. With osm2pgsql being the tool used in the default map rendering on osm.org and the prevalence of tagging for the renderer decisions on how it handles multipolygons will (and imho to a limited degree should) influence how people tag and what they perceive as correct tagging. Therefore it is important that there is a consensus of what the correct tagging schema is and make sure that is correctly supported by osm2pgsql. That is also why I think having this discussion on talk, rather than on github or the dev list is appropriate. We need to come to a consensus between all of the main tools (at least iD, P2, JOSM, osm2pgsql, osrm, ...) and the mappers to what the preferred, encouraged and supported standard for tagging multi-polygons is and make sure that all documentation is in line with this. -- View this message in context: http://gis.19327.n5.nabble.com/osm2pgsql-multipolygon-parsing-tp5778300p5778654.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql multipolygon parsing
Am 22/set/2013 um 04:14 schrieb Eugene Alvin Villar sea...@gmail.com: It's most likely that these people are not familiar with relations and they see an outer way with no building=yes tag and decided to helpfully tag it. Because of this, a more complicated interpretation of tags, such as Frederik's, leads to less breakage (think rendering) and is more in line with people's expectations. it leads to more broken data in the end, because it will continue to look OK on the map and many mappers are checking this visual feedback in order to judge their mapping. cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql multipolygon parsing
Am 22.09.2013 04:14, schrieb Eugene Alvin Villar: I agree that this is a good way of tagging multipolygons. Unfortunately, many people don't tag multipolygons in this way. I've seen people add building=yes to an outer way of a building with holes even though there's a multipolygon relation with that tag already. It's most likely that these people are not familiar with relations and they see an outer way with no building=yes tag and decided to helpfully tag it. Because of this, a more complicated interpretation of tags, such as Frederik's, leads to less breakage (think rendering) and is more in line with people's expectations. Because of this I agree with Frederiks approach for any consumer-map to produce. If I would print a map for a customer, I would follow his assumptions most probably, but I disagree for the default style(s) on the osm.org website, as these in fact are driving factors to how people tag. If people tag multipolygons right (tm), this should be honoured by a correct display on the map. If it's wrong they should see that there's an error, therefore IMHO the default stylesheet MUST NOT gracefully forgive these errors as a map more dedicated to end users would probably do. Following these assumptions on the main map which is often used to check the correctness of the own edits means to hide errors and to tell mappers the wrong thing: you have done all right - where that's not the case. regards Peter ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql multipolygon parsing
Osm2pgsql is not used for the default map on osm.org. While the current behaviour in osm2pgsql is OK for consumers, could a 'strict' mode to handle mutipolygons be used on osm.org default map ? Of course, it should be accompagnied with a large campaign of multi-polygons fix. Yves ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql multipolygon parsing
2013/9/22 yvecai yve...@gmail.com Of course, it should be accompagnied with a large campaign of multi-polygons fix. I'd suggest to start modifying the recommendations in the wiki: http://wiki.openstreetmap.org/wiki/Multipolygon reads: If you have one closed way making up the outer ring and it does not describe something in its own right, you *may* also put these tags on the outer ring and leave the relation untagged. The suggestion is to discourage this in all cases and encourage always tagging the relation (this is also straightforward and much easier as you can do A or B). cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql multipolygon parsing
On 22/09/2013 10:03, yvecai wrote: Of course, it should be accompagnied with a large campaign of multi-polygons fix. ... and a patch to any editors that don't create multipolygons in this format. For example, here are three attempts at multipolygons in iD, P2 and JOSM: http://api06.dev.openstreetmap.org/#map=15/53.2692/-0.2806layers=D (you may need to turn the data layer on manually to see the them) The left-hand one was me trying to create one in iD (I've not worked out how to do that yet). The middle one is P2, and the right-hand one is JOSM. You'll notice that the right-hand one doesn't render in P2 despite being the arguably the more logically-tagged. I suspect that this is and has been for some time a patches welcome type of situation. Cheers, Andy ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql multipolygon parsing
Am 22.09.2013 11:31, schrieb Martin Koppenhoefer: 2013/9/22 yvecai yve...@gmail.com Of course, it should be accompagnied with a large campaign of multi-polygons fix. I'd suggest to start modifying the recommendations in the wiki: http://wiki.openstreetmap.org/wiki/Multipolygon reads: If you have one closed way making up the outer ring and it does not describe something in its own right, you *may* also put these tags on the outer ring and leave the relation untagged. The suggestion is to discourage this in all cases and encourage always tagging the relation (this is also straightforward and much easier as you can do A or B). +1 regards Peter ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql multipolygon parsing
Hi, The remaining question is, what should be the correct behavior? My assumption until now was: * If a multipolygon is untagged - where untagged means that it has no tags except a small list (type, source, source:*, note) then it will simply receive *all* tags from all (outer) member ways, but processing will fail if these tags differ in values. * If the multipolygon is tagged (with anything except type, source, note etc) then those are the tags for the polygon and way tags will not be looked at. * If the tags of the inner way differ from the tags of the outer way or the tags of the relation, except source, note etc., then the inner way will become a separate polygon. All this was without trying to make a judgement about which tags are polygon tags and which aren't. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql multipolygon parsing
2013/9/21 Frederik Ramm frede...@remote.org Hi, The remaining question is, what should be the correct behavior? My assumption until now was: * If a multipolygon is untagged - where untagged means that it has no tags except a small list (type, source, source:*, note) then it will simply receive *all* tags from all (outer) member ways, but processing will fail if these tags differ in values. but this introduces a lot of complexity, especially in the case of MPs with many outer members, when you only want to modify the tags of a single one of these (outer) ways. Many editors (e.g. on smartphones) will not even notify you that the way is part of a relation. * If the multipolygon is tagged (with anything except type, source, note etc) then those are the tags for the polygon and way tags will not be looked at. do you also include name in this list? * If the tags of the inner way differ from the tags of the outer way or the tags of the relation, except source, note etc., then the inner way will become a separate polygon. all tags, or only the relevant ones? And if yes, which ones aren't relevant? And also here there might be cases where e.g. inside a forest you will want to have another forest because of some properties they don't share (be it name but also note etc.) cheers, Martin ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql multipolygon parsing
IMHO it's clear:
- a tag on a way describes that way, if it's a closed way and the tag is
describing an area, the tag matches the complete area inside that polygon.
- if a way is outer of a multipolygon and there are tags on the way,
these tags nevertheless describe the whole area, including all holes, as
it's still a tag on the (simple) polygon.
- if a way is inner of a multipolygon and there are tags on the way,
these tags describe the polygon described by this way.
- tags on the multipolygon relation describe the area represented by the
relation - that is all outer polygons minus the inner polygons.
If we follow this assumption, it's
1) not conflicting with double-tagging, which is in fact often useful.
Example: A big park with a lake in the middle of a big lawn.
- the whole area (including lawn and lake) is a park = the outer
polygon is tagged as a park
- only the small patch in the middle is a lake = the inner polygon is
tagged as a lake
- the whole area except the lake surface is a lawn = tag the
multipolygon as lawn.
Tags:
outer: {leisure=park}
inner: {natural=water}
mp:{landuse=grass}
2) it's unambiguous
Following Frederiks assumptions instead my tagging of the example above
would be interpreted as:
- area of the multipolygon (outer minus inner): leisure=park
- inner: natural=water
- whole area: no attributes (am I right?)
Thus the park is missing now (or Frederiks description is incomplete).
An even better example is one where the inner has a subset of the
multipolygon tags, let's say:
mp: {landuse=forest, wood=coniferous}
inner: {landuse=forest}
Frederiks assumption lead here to:
- mp: landuse=forest, wood=coniferous
- inner: untagged, as the tags are ignored because they don't differ
from the mp.
regards
Peter
Am 21.09.2013 17:00, schrieb Frederik Ramm:
Hi,
The remaining question is, what should be the correct behavior?
My assumption until now was:
* If a multipolygon is untagged - where untagged means that it has no
tags except a small list (type, source, source:*, note) then it will
simply receive *all* tags from all (outer) member ways, but processing
will fail if these tags differ in values.
* If the multipolygon is tagged (with anything except type, source, note
etc) then those are the tags for the polygon and way tags will not be
looked at.
* If the tags of the inner way differ from the tags of the outer way or
the tags of the relation, except source, note etc., then the inner way
will become a separate polygon.
All this was without trying to make a judgement about which tags are
polygon tags and which aren't.
Bye
Frederik
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm2pgsql multipolygon parsing
On Sun, Sep 22, 2013 at 4:51 AM, Peter Wendorff wendo...@uni-paderborn.dewrote: IMHO it's clear: - a tag on a way describes that way, if it's a closed way and the tag is describing an area, the tag matches the complete area inside that polygon. - if a way is outer of a multipolygon and there are tags on the way, these tags nevertheless describe the whole area, including all holes, as it's still a tag on the (simple) polygon. - if a way is inner of a multipolygon and there are tags on the way, these tags describe the polygon described by this way. - tags on the multipolygon relation describe the area represented by the relation - that is all outer polygons minus the inner polygons. I agree that this is a good way of tagging multipolygons. Unfortunately, many people don't tag multipolygons in this way. I've seen people add building=yes to an outer way of a building with holes even though there's a multipolygon relation with that tag already. It's most likely that these people are not familiar with relations and they see an outer way with no building=yes tag and decided to helpfully tag it. Because of this, a more complicated interpretation of tags, such as Frederik's, leads to less breakage (think rendering) and is more in line with people's expectations. ___ talk mailing list talk@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk
