logo separator

[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
>



More information about the mkgmap-dev mailing list