[mkgmap-dev] type=multipolygon relations
From WanMil wmgcnfg at web.de on Sun Jan 19 19:20:52 GMT 2014
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 at .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 at .org > >>> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>> >>> >>> _______________________________________________ >>> mkgmap-dev mailing list >>> > >> mkgmap-dev at .org > >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>> >> >> _______________________________________________ >> mkgmap-dev mailing list > >> mkgmap-dev at .org > >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev > > > > > > -- > View this message in context: http://gis.19327.n5.nabble.com/type-multipolygon-relations-tp5793518p5793632.html > Sent from the Mkgmap Development mailing list archive at Nabble.com. > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev at lists.mkgmap.org.uk > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >
- Previous message: [mkgmap-dev] type=multipolygon relations
- Next message: [mkgmap-dev] type=multipolygon relations
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list