Hi all, from time to time I stumble over mp like this: http://www.openstreetmap.org/relation/3318482 It contains way 135320941 three times. In other cases inner ways are duplicated, and that really causes trouble when calculating the areas. I wonder why we don't remove duplicate entries when we process the members of mp relations. Is there any possible constellation where this would cause trouble? Gerd
Hi Gerd, I never thought about such a case. Does it cause trouble for you with the new shape merger? WanMil
Hi all,
from time to time I stumble over mp like this: http://www.openstreetmap.org/relation/3318482
It contains way 135320941 three times. In other cases inner ways are duplicated, and that really causes trouble when calculating the areas.
I wonder why we don't remove duplicate entries when we process the members of mp relations. Is there any possible constellation where this would cause trouble?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, no, I don't think so. I seem to remeber in some cases it caused trouble in the mp code itself, but forgot the exact case, I just found this relation while trying (again) to change mp code (and Java2DConverter) to use high precision. Gerd
Date: Sat, 18 Jan 2014 16:36:55 +0100 From: wmgcnfg@web.de To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] type=multipolygon relations
Hi Gerd,
I never thought about such a case. Does it cause trouble for you with the new shape merger?
WanMil
Hi all,
from time to time I stumble over mp like this: http://www.openstreetmap.org/relation/3318482
It contains way 135320941 three times. In other cases inner ways are duplicated, and that really causes trouble when calculating the areas.
I wonder why we don't remove duplicate entries when we process the members of mp relations. Is there any possible constellation where this would cause trouble?
Gerd
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
On Sat, Jan 18, 2014 at 04:30:34PM +0100, Gerd Petermann wrote:
I wonder why we don't remove duplicate entries when we process the members of mp relations. Is there any possible constellation where this would cause trouble?
I cannot think of any. It should also not make any sense for the same way to be in different roles in a multipolygon relation. (In a route relation, you could have the same way twice, in role=forward and role=backward. You might even have a way multiple times, if the route is visiting points A, B, A, C, A.) The JOSM relation editor is highlighting duplicate relation members. I think that it would be good to issue a log message for the duplicate multipolygon members, so that the data can be corrected (simplified). Marko
Good luck for correcting them, there are tons of those faulty mp's all over the place in NL's ;-) I wouldnt spend too much time for this, better ignore it. The guy who imported those 3D-landuse shapes almost risked his health :-/
I cannot think of any. It should also not make any sense for the same way to be in different roles in a multipolygon relation.
(In a route relation, you could have the same way twice, in role=forward and role=backward. You might even have a way multiple times, if the route is visiting points A, B, A, C, A.)
The JOSM relation editor is highlighting duplicate relation members. I think that it would be good to issue a log message for the duplicate multipolygon members, so that the data can be corrected (simplified).
Marko
On Sat, Jan 18, 2014 at 10:58:58PM +0100, Minko wrote:
Good luck for correcting them, there are tons of those faulty mp's all over the place in NL's ;-) I wouldnt spend too much time for this, better ignore it.
I have found the existing multipolygon and coastline warnings very useful. The check for duplicate member ID in a multipolygon relation is cheap and has to be done anyway. There is really no good reason not to warn about them. By default, the log output is not enabled. You have to specify -Dlog.config=logging.properties in order to enable the diagnostic. Even after doing so, you could filter out these particular messages either by grep -vf or by configuring the logging.properties file appropriately. Marko
HI Marko, I agree that this should be flagged. I tried it with the data for Netherlands and I see no other problems besides the one in my example, so it doesn't see to happen that often. Attached small patch changes mkgmap so that repeated elements are ignored (the first one is used, ignoring differences in roles) If I hear no complains I will commit it next weekend. Gerd
Date: Sun, 19 Jan 2014 00:16:15 +0200 From: marko.makela@iki.fi To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] type=multipolygon relations
On Sat, Jan 18, 2014 at 10:58:58PM +0100, Minko wrote:
Good luck for correcting them, there are tons of those faulty mp's all over the place in NL's ;-) I wouldnt spend too much time for this, better ignore it.
I have found the existing multipolygon and coastline warnings very useful. The check for duplicate member ID in a multipolygon relation is cheap and has to be done anyway. There is really no good reason not to warn about them.
By default, the log output is not enabled. You have to specify -Dlog.config=logging.properties in order to enable the diagnostic. Even after doing so, you could filter out these particular messages either by grep -vf or by configuring the logging.properties file appropriately.
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi Gerd, from my point of view it's ok to remove duplicate ways from mps. Anyhow I didn't find a sentence on http://wiki.openstreetmap.org/wiki/Multipolygon that this is disallowed. I can think of two touching inner polygons: 11111111111111111111111111 1 1 1 22234444 1 1 2 3 4 1 1 2 3 4 1 1 22234444 1 1 1 11111111111111111111111111 MP: tags natural=forest Way 1: role=outer Way 2: role=inner, natrual=scrub Way 3: role=inner, natrual=scrub Way 4: role=inner, natrual=scrub It seems to be allowed to have 2+3 and 3+4 as inner polygons in the mp. In this case way 3 would have to be added twice to the mp. I think we can ignore such a case but we should keep it in mind. WanMil
HI Marko,
I agree that this should be flagged. I tried it with the data for Netherlands and I see no other problems besides the one in my example, so it doesn't see to happen that often.
Attached small patch changes mkgmap so that repeated elements are ignored (the first one is used, ignoring differences in roles)
If I hear no complains I will commit it next weekend.
Gerd
Date: Sun, 19 Jan 2014 00:16:15 +0200 From: marko.makela@iki.fi To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] type=multipolygon relations
On Sat, Jan 18, 2014 at 10:58:58PM +0100, Minko wrote:
Good luck for correcting them, there are tons of those faulty mp's all over the place in NL's ;-) I wouldnt spend too much time for this, better ignore it.
I have found the existing multipolygon and coastline warnings very useful. The check for duplicate member ID in a multipolygon relation is cheap and has to be done anyway. There is really no good reason not to warn about them.
By default, the log output is not enabled. You have to specify -Dlog.config=logging.properties in order to enable the diagnostic. Even after doing so, you could filter out these particular messages either by grep -vf or by configuring the logging.properties file appropriately.
Marko _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, I think your example is not valid. One rule in that wiki says: "If an endpoint is shared by more than two unclosed ways, it's ill formed and a closed polygon can't be reconstructed unambiguously." I think both end points of 3 are shared by three unclosed ways. Gerd WanMil wrote
Hi Gerd,
from my point of view it's ok to remove duplicate ways from mps.
Anyhow I didn't find a sentence on http://wiki.openstreetmap.org/wiki/Multipolygon that this is disallowed. I can think of two touching inner polygons:
11111111111111111111111111 1 1 1 22234444 1 1 2 3 4 1 1 2 3 4 1 1 22234444 1 1 1 11111111111111111111111111
MP: tags natural=forest Way 1: role=outer Way 2: role=inner, natrual=scrub Way 3: role=inner, natrual=scrub Way 4: role=inner, natrual=scrub
It seems to be allowed to have 2+3 and 3+4 as inner polygons in the mp. In this case way 3 would have to be added twice to the mp.
I think we can ignore such a case but we should keep it in mind.
WanMil
HI Marko,
I agree that this should be flagged. I tried it with the data for Netherlands and I see no other problems besides the one in my example, so it doesn't see to happen that often.
Attached small patch changes mkgmap so that repeated elements are ignored (the first one is used, ignoring differences in roles)
If I hear no complains I will commit it next weekend.
Gerd
Date: Sun, 19 Jan 2014 00:16:15 +0200 From:
marko.makela@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] type=multipolygon relations
On Sat, Jan 18, 2014 at 10:58:58PM +0100, Minko wrote:
Good luck for correcting them, there are tons of those faulty mp's all over the place in NL's ;-) I wouldnt spend too much time for this, better ignore it.
I have found the existing multipolygon and coastline warnings very useful. The check for duplicate member ID in a multipolygon relation is cheap and has to be done anyway. There is really no good reason not to warn about them.
By default, the log output is not enabled. You have to specify -Dlog.config=logging.properties in order to enable the diagnostic. Even after doing so, you could filter out these particular messages either by grep -vf or by configuring the logging.properties file appropriately.
Marko _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/type-multipolygon-relations-tp5793518p5793632... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Ahh, that's fine. Unfortunately it shows the big problem of mps: thery are much too complicated (but this is not relevant for mkgmap - we have to support it until they are replaced by another OSM data structure). Does that also mean that we should another check for that? WanMil
Hi WanMil,
I think your example is not valid. One rule in that wiki says: "If an endpoint is shared by more than two unclosed ways, it's ill formed and a closed polygon can't be reconstructed unambiguously." I think both end points of 3 are shared by three unclosed ways.
Gerd
WanMil wrote
Hi Gerd,
from my point of view it's ok to remove duplicate ways from mps.
Anyhow I didn't find a sentence on http://wiki.openstreetmap.org/wiki/Multipolygon that this is disallowed. I can think of two touching inner polygons:
11111111111111111111111111 1 1 1 22234444 1 1 2 3 4 1 1 2 3 4 1 1 22234444 1 1 1 11111111111111111111111111
MP: tags natural=forest Way 1: role=outer Way 2: role=inner, natrual=scrub Way 3: role=inner, natrual=scrub Way 4: role=inner, natrual=scrub
It seems to be allowed to have 2+3 and 3+4 as inner polygons in the mp. In this case way 3 would have to be added twice to the mp.
I think we can ignore such a case but we should keep it in mind.
WanMil
HI Marko,
I agree that this should be flagged. I tried it with the data for Netherlands and I see no other problems besides the one in my example, so it doesn't see to happen that often.
Attached small patch changes mkgmap so that repeated elements are ignored (the first one is used, ignoring differences in roles)
If I hear no complains I will commit it next weekend.
Gerd
Date: Sun, 19 Jan 2014 00:16:15 +0200 From:
marko.makela@
To:
mkgmap-dev@.org
Subject: Re: [mkgmap-dev] type=multipolygon relations
On Sat, Jan 18, 2014 at 10:58:58PM +0100, Minko wrote:
Good luck for correcting them, there are tons of those faulty mp's all over the place in NL's ;-) I wouldnt spend too much time for this, better ignore it.
I have found the existing multipolygon and coastline warnings very useful. The check for duplicate member ID in a multipolygon relation is cheap and has to be done anyway. There is really no good reason not to warn about them.
By default, the log output is not enabled. You have to specify -Dlog.config=logging.properties in order to enable the diagnostic. Even after doing so, you could filter out these particular messages either by grep -vf or by configuring the logging.properties file appropriately.
Marko _______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/type-multipolygon-relations-tp5793518p5793632... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
Hi WanMil, WanMil wrote
Ahh, that's fine. Unfortunately it shows the big problem of mps: thery are much too complicated (but this is not relevant for mkgmap - we have to support it until they are replaced by another OSM data structure).
Does that also mean that we should another check for that?
yes, I did not yet look deeply into the code, but I guess we can use this rule to simplify the routine that joins ways? Question is: what should happen if a relation doesn't meet the criteria? Ignore it completely or ignore elements that are invalid? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/type-multipolygon-relations-tp5793518p5793636... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hi WanMil,
WanMil wrote
Ahh, that's fine. Unfortunately it shows the big problem of mps: thery are much too complicated (but this is not relevant for mkgmap - we have to support it until they are replaced by another OSM data structure).
Does that also mean that we should another check for that?
yes, I did not yet look deeply into the code, but I guess we can use this rule to simplify the routine that joins ways? Question is: what should happen if a relation doesn't meet the criteria? Ignore it completely or ignore elements that are invalid?
Gerd
Hi Gerd, I don't think that the routine that joins ways will become easier. The task is still the same (join n ways at point p) and the existing routine does not have any error handling (like a backtracking algorithm when a join does not lead to a closed polygon). So an additional warning should be enough from my point of view. WanMil
Hi WanMil, Gerd, On Sun, Jan 19, 2014 at 10:47:15AM -0800, GerdP wrote:
Hi WanMil,
I think your example is not valid. One rule in that wiki says: "If an endpoint is shared by more than two unclosed ways, it's ill formed and a closed polygon can't be reconstructed unambiguously." I think both end points of 3 are shared by three unclosed ways.
I agree with Gerd that the example is not valid:
11111111111111111111111111 1 1 1 22234444 1 1 2 3 4 1 1 2 3 4 1 1 22234444 1 1 1 11111111111111111111111111
MP: tags natural=forest Way 1: role=outer Way 2: role=inner, natrual=scrub Way 3: role=inner, natrual=scrub Way 4: role=inner, natrual=scrub
I think that this should be mapped with 3 multipolygon relations: MP1: natural=forest: role=outer: way1, role=inner: way2, way4 MP2: natural=scrub: role=outer: way2, way3 MP3: natural=scrub: role=outer: way3, way4 If you really meant natural=scrub for both 2+3 and 3+4, I think that this could be simplified by removing way 3 and merging ways 2 and 4. The example would make more sense if MP3 is tagged as natural=water, for instance. In my opinion, mkgmap should issue a warning for the duplicate way 3 for your example. It does not seem much different from a situation where two inner polygons are touching or intersecting each other. I think that the unambiguous way of mapping is to draw a bigger hole around the adjacent areas, like MP1 in the above example does. Marko
participants (5)
-
Gerd Petermann -
GerdP
-
Marko Mäkelä -
Minko -
WanMil