<div dir="ltr"><div><div>Nope - it's not the splitter - it's fully within one tile. I guess there is a bug in the style parser together with area_size() filter and continue command?<br><br>I actually looked at it with gpsmapedit - and I see the island is cut out - but additionally to the cut out water is put into it. The only lines in my polygons file that can be related to it are as follows:<br></div>(note the flooded island also exists at resolution 18 as 0x3c - so all other lines are only relevant for the key 20resolution!=yes).<br></div>I put those lines which should not fire in grey. Chiemsee is natural=water & water=lake.<br><div><div><span style="color:rgb(153,153,153)"><br>( natural=forest | landuse=wood | natural=forrest | landuse=forrest ) {set landuse=forest}<br>( landuse=forest | natural=wood ) {set 20resolution=yes} [0x50 resolution 18-20 continue with_actions]<br>( natural=glacier | landuse=glacier ) & 20resolution!=yes {set 20resolution=yes} [0x4d resolution 18-21 continue with_actions]</span><br><br>( natural=lake | ( natural=water & water=lake)) & 20resolution!=yes {set 20resolution=yes} [0x3c resolution 18-21 continue with_actions]<br><span style="color:rgb(153,153,153)">natural=water & water=oxbow & 20resolution!=yes {set 20resolution=yes} [0x3c resolution 20-21 continue with_actions]<br>natural=water & ( water=cove | water=lagoon ) & 20resolution!=yes {set 20resolution=yes} [0x3c resolution 21-21 continue with_actions]</span><br><span style="color:rgb(153,153,153)">natural=water & water=* & water!=lake & water!=reservoir & water!=canal & water!=river & water!=yes & water!=Cove & water!=bay & water!=Lake & area_size() < 1000 & 20resolution!=yes {set 20resolution=yes}</span><br><span style="color:rgb(153,153,153)">natural=water & water=reflecting_pool & 20resolution!=yes {set 20resolution=yes}<br>natural=water & water=lock & 20resolution!=yes {set 20resolution=yes}<br>natural=water & water=moat & 20resolution!=yes {set 20resolution=yes}<br>natural=water & water=wastewater & 20resolution!=yes {set 20resolution=yes}<br>natural=water & ( water=shallow | water=drain | water=well | water=salt_pool | water='Salt_pool' ) & 20resolution!=yes {set 20resolution=yes}<br>natural=water & ( water=intermittent | intermettent=yes ) & 20resolution!=yes {set 20resolution=yes}<br>natural=water & ( water=reservoir | water=canal ) & 20resolution!=yes {set 20resolution=yes} [0x3c resolution 19-21 continue with_actions]</span><br>natural=water & 20resolution!=yes & area_size() > 2000 {set 20resolution=yes} [0x3c resolution 18-21 continue with_actions]<br><br><br><br></div><div>Is there maybe a bug related to the area_size() filter and Multipolygons?<br><br></div><div>(not I did not use yet this mornings patch). Right now my server is blocked - I can try out things only from tomorrow onwards.<br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 29 July 2016 at 07:07, Gerd Petermann <span dir="ltr"><<a href="mailto:GPetermann_muenchen@hotmail.com" target="_blank">GPetermann_muenchen@hotmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div>
<div style="font-size:12pt;color:#000000;background-color:#ffffff;font-family:Calibri,Arial,Helvetica,sans-serif">
<p>Hi Felix,</p>
<p><br>
</p>
<p>okay. In case that you also used splitter to calculate new tiles a possible explanation
<br>
</p>
<p>might be a special case at tile boundaries, although the --keep-complete option should</p>
<p>avoid that.<br>
</p>
<p><br>
</p>
<p>Gerd<br>
</p>
</div>
<hr style="display:inline-block;width:98%">
<div dir="ltr"><font style="font-size:11pt" face="Calibri, sans-serif" color="#000000"><b>Von:</b> mkgmap-dev <<a href="mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk" target="_blank">mkgmap-dev-bounces@lists.mkgmap.org.uk</a>> im Auftrag von Felix Hartmann <<a href="mailto:extremecarver@gmail.com" target="_blank">extremecarver@gmail.com</a>><br>
<b>Gesendet:</b> Freitag, 29. Juli 2016 00:11:45<span class=""><br>
<b>An:</b> Development list for mkgmap<br>
</span><b>Betreff:</b> Re: [mkgmap-dev] Option to output polygons in size order</font>
<div> </div>
</div><div><div class="h5">
<div>
<div dir="ltr">Well - recompiled and this time the Chieemsee is fine. Really do wonder why it missed the islands. Next time someone reports somethink like this - or I notice a problem somewhere I'll report on time...<br>
</div>
<div class="gmail_extra"><br>
<div class="gmail_quote">On 27 July 2016 at 16:08, Thorsten Kukuk <span dir="ltr">
<<a href="mailto:kukuk@suse.de" target="_blank">kukuk@suse.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span>On Wed, Jul 27, Felix Hartmann wrote:<br>
<br>
> Ah - I guess the Chieemsee will be taken from the sea input files - won't<br>
> it?<br>
<br>
</span>No, it does not. Lakes are natural=water and most of the time multipolygones.<br>
<span><br>
> I never really now what water features are taken from which input.<br>
<br>
</span>Quite easy: coastline, and only coastlines, are taken from the sea input.<br>
Lakes are no sea.<br>
<span><br>
> If<br>
> not I would really wonder why all islands in the Chieemsee are flooded for<br>
> me. The Chieemsee was updated last time 20 days ago - so I should have the<br>
> correct data if it is taken from the normal osm.pbf file.<br>
<br>
</span>On my map, the Chiemsee including the three islands, is correct, no flooding<br>
anywhere.<br>
<br>
Thorsten<br>
<span><br>
> I used them since 10.06.2016 without update. I just uploaded the version I<br>
> use here: <a href="https://openmtbmap.org/sea.zip" rel="noreferrer" target="_blank">
https://openmtbmap.org/sea.zip</a><br>
><br>
><br>
> Felix<br>
><br>
><br>
><br>
> On 27 July 2016 at 15:14, Gerd Petermann <<a href="mailto:GPetermann_muenchen@hotmail.com" target="_blank">GPetermann_muenchen@hotmail.com</a>><br>
> wrote:<br>
><br>
> > Hmm,<br>
> ><br>
> ><br>
> > the way 4605746 is an inner member of mp-relation<br>
> > <a href="https://www.openstreetmap.org/relation/32246" rel="noreferrer" target="_blank">
https://www.openstreetmap.org/relation/32246</a><br>
> ><br>
> > I see no problems with the default style. Do you still have the 18.07.<br>
> > data ?<br>
> ><br>
> ><br>
> > Gerd<br>
> ><br>
> ><br>
</span>> > ------------------------------<br>
> > *Von:* mkgmap-dev <<a href="mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk" target="_blank">mkgmap-dev-bounces@lists.mkgmap.org.uk</a>> im Auftrag von<br>
> > Felix Hartmann <<a href="mailto:extremecarver@gmail.com" target="_blank">extremecarver@gmail.com</a>><br>
> > *Gesendet:* Mittwoch, 27. Juli 2016 14:59:51<br>
> ><br>
> > *An:* Development list for mkgmap<br>
> > *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order<br>
<span>> ><br>
> > Oh - check the Herreninsel Chieemsee. It was flooded based on 18.07 data<br>
> > and already flodded in June. Was fine in March though.<br>
> ><br>
> > <a href="http://www.openstreetmap.org/way/4605746" rel="noreferrer" target="_blank">
http://www.openstreetmap.org/way/4605746</a><br>
> ><br>
> > It should be a multipolygon but it's not. It's much smaller than the lake<br>
> > however. Basically right now in my map the whole forest is flooded. Also<br>
> > Fraueninsel flooded. Mapnik get'r it right however!<br>
> ><br>
> > On 27 July 2016 at 14:52, Felix Hartmann <<a href="mailto:extremecarver@gmail.com" target="_blank">extremecarver@gmail.com</a>> wrote:<br>
> ><br>
> >> Know - sadly not. Usually such places are fixed up sooner or later - and<br>
> >> then sometimes destroyed again. It's kinda hard to find them too - because<br>
> >> you will either give lake or water preference (or give it same<br>
> >> draw-priority and end up with chance). I just know since I implemented a<br>
> >> limited layer approach - complaints about something "missing" are much more<br>
> >> rare.<br>
> >><br>
> >> On 27 July 2016 at 14:44, Gerd Petermann <<a href="mailto:GPetermann_muenchen@hotmail.com" target="_blank">GPetermann_muenchen@hotmail.com</a><br>
> >> > wrote:<br>
> >><br>
> >>> Hi Felix,<br>
> >>><br>
> >>><br>
> >>> okay, I like the idea reg. layer, but I was not yet able to find an<br>
> >>> example in OSM.<br>
> >>><br>
> >>> I assume the problem appears only in specific regions wheres such an<br>
> >>> unexperienced<br>
> >>><br>
> >>> mapper is active. Do you know such a region?<br>
> >>><br>
> >>><br>
> >>> Gerd<br>
> >>><br>
> >>><br>
</span>> >>> ------------------------------<br>
> >>> *Von:* mkgmap-dev <<a href="mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk" target="_blank">mkgmap-dev-bounces@lists.mkgmap.org.uk</a>> im Auftrag<br>
> >>> von Felix Hartmann <<a href="mailto:extremecarver@gmail.com" target="_blank">extremecarver@gmail.com</a>><br>
> >>> *Gesendet:* Mittwoch, 27. Juli 2016 14:31:28<br>
> >>><br>
> >>> *An:* Development list for mkgmap<br>
> >>> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order<br>
<div>
<div>> >>><br>
> >>> Well the smaller polygon in usual is the one that people expect to end<br>
> >>> up on top. HOWEVER - before even checking for size - there could be a check<br>
> >>> for the layer tag. It is still commonly used by people who do not<br>
> >>> understand how to use multipolygons.<br>
> >>><br>
> >>> So an approach could be - take polygon overlap check for values defined<br>
> >>> in "overlap" style-file - after multipolgyon overlap is gone.<br>
> >>> Check if layer tag is present on either of the polygons. If yes - then<br>
> >>> cut out according to layer.<br>
> >>> If not - cut out the smaller from the bigger. Usually it's the smaller<br>
> >>> polygon that should appear.<br>
> >>><br>
> >>> I guess it needs to happen quite late therefore. Why smaller - well<br>
> >>> quite often people contacted me about islands missing/flooded or similar -<br>
> >>> and usually it was the smaller polygon that should have been on top. I<br>
> >>> guess with layer tag however 90% of all cases can already be resolved. (I<br>
> >>> do this in a very limited way already - by having some polygons like water<br>
> >>> and forest in several versions with different priority based on layer tag -<br>
> >>> this did help a lot)<br>
> >>><br>
> >>> Felix<br>
> >>><br>
> >>> On 27 July 2016 at 13:41, Gerd Petermann <<br>
> >>> <a href="mailto:GPetermann_muenchen@hotmail.com" target="_blank">GPetermann_muenchen@hotmail.com</a>> wrote:<br>
> >>><br>
> >>>> Hi Felix,<br>
> >>>><br>
> >>>><br>
> >>>> okay, maybe I'll add this as an experimental option as well.<br>
> >>>><br>
> >>>> One big question here is: At what point would the cutting<br>
> >>>><br>
> >>>> happen? Before style processing (as we do with mp-relations)<br>
> >>>><br>
> >>>> or maybe as a new stage before the img data is written.<br>
> >>>><br>
> >>>><br>
> >>>> What I don't yet understand is the idea that a smaller<br>
> >>>><br>
> >>>> polygon is more important. Do you have examples for that,<br>
> >>>><br>
> >>>> esp. cases where shapes do only partially overlap?<br>
> >>>><br>
> >>>><br>
> >>>> Gerd<br>
</div>
</div>
> >>>> ------------------------------<br>
> >>>> *Von:* mkgmap-dev <<a href="mailto:mkgmap-dev-bounces@lists.mkgmap.org.uk" target="_blank">mkgmap-dev-bounces@lists.mkgmap.org.uk</a>> im Auftrag<br>
> >>>> von Felix Hartmann <<a href="mailto:extremecarver@gmail.com" target="_blank">extremecarver@gmail.com</a>><br>
> >>>> *Gesendet:* Mittwoch, 27. Juli 2016 13:24:37<br>
> >>>> *An:* Development list for mkgmap<br>
> >>>> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order<br>
<div>
<div>> >>>><br>
> >>>><br>
> >>>> On 27 July 2016 at 09:29, Gerd Petermann <<br>
> >>>> <a href="mailto:GPetermann_muenchen@hotmail.com" target="_blank">GPetermann_muenchen@hotmail.com</a>> wrote:<br>
> >>>><br>
> >>>>> reg. the idea of "cutting out overlaps": I guess it would consume<br>
> >>>>> quite a lot of CPU and it would heavily increase the img size<br>
> >>>>><br>
> >>>>> because we would have to write many more points. Think of a shape for<br>
> >>>>> "place=village" with hundreds of holes for each building<br>
> >>>>><br>
> >>>>> shape. Up to now we save the shape for the village and the shapes for<br>
> >>>>> the buildings. With cutting we have to calculate what<br>
> >>>>><br>
> >>>>> remains of the village shape, this would be a very complex shape with<br>
> >>>>> many holes, so it would have many points.<br>
> >>>>><br>
> >>>>> I don't think that would be a good idea.<br>
> >>>>><br>
> >>>>><br>
> >>>> Well that's why I wrote we will need an additional file in the<br>
> >>>> style-file for this. So only for certain polygons this should be done.<br>
> >>>> Prime examples are: any kind of forest, most kind of water, and maybe a<br>
> >>>> handful more. However definitely not buildings or for example poygons you<br>
> >>>> can put semi-transparent.<br>
> >>>><br>
> >>>> I'm quite sure with this limited approach 90% of problems would be<br>
> >>>> gone. And mapsize only a couple percent bigger. However I have no clue<br>
> >>>> about complexity and CPU cycles for such a limited approach.<br>
> >>>><br>
> >>>><br>
> >>>> --<br>
> >>>> Felix Hartman - Openmtbmap.org & VeloMap.org<br>
> >>>> Schusterbergweg 32/8<br>
> >>>> 6020 Innsbruck<br>
> >>>> Austria - Österreich<br>
> >>>><br>
> >>>> _______________________________________________<br>
> >>>> mkgmap-dev mailing list<br>
> >>>> <a href="mailto:mkgmap-dev@lists.mkgmap.org.uk" target="_blank">mkgmap-dev@lists.mkgmap.org.uk</a><br>
> >>>> <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
> >>>><br>
> >>><br>
> >>><br>
> >>><br>
> >>> --<br>
> >>> Felix Hartman - Openmtbmap.org & VeloMap.org<br>
> >>> Schusterbergweg 32/8<br>
> >>> 6020 Innsbruck<br>
> >>> Austria - Österreich<br>
> >>><br>
> >>> _______________________________________________<br>
> >>> mkgmap-dev mailing list<br>
> >>> <a href="mailto:mkgmap-dev@lists.mkgmap.org.uk" target="_blank">mkgmap-dev@lists.mkgmap.org.uk</a><br>
> >>> <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
> >>><br>
> >><br>
> >><br>
> >><br>
> >> --<br>
> >> Felix Hartman - Openmtbmap.org & VeloMap.org<br>
> >> Schusterbergweg 32/8<br>
> >> 6020 Innsbruck<br>
> >> Austria - Österreich<br>
> >><br>
> ><br>
> ><br>
> ><br>
> > --<br>
> > Felix Hartman - Openmtbmap.org & VeloMap.org<br>
> > Schusterbergweg 32/8<br>
> > 6020 Innsbruck<br>
> > Austria - Österreich<br>
> ><br>
> > _______________________________________________<br>
> > mkgmap-dev mailing list<br>
> > <a href="mailto:mkgmap-dev@lists.mkgmap.org.uk" target="_blank">mkgmap-dev@lists.mkgmap.org.uk</a><br>
> > <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
> ><br>
><br>
><br>
><br>
> --<br>
> Felix Hartman - Openmtbmap.org & VeloMap.org<br>
> Schusterbergweg 32/8<br>
> 6020 Innsbruck<br>
> Austria - Österreich<br>
<br>
> _______________________________________________<br>
> mkgmap-dev mailing list<br>
> <a href="mailto:mkgmap-dev@lists.mkgmap.org.uk" target="_blank">mkgmap-dev@lists.mkgmap.org.uk</a><br>
> <a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">
http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
<br>
<br>
--<br>
</div>
</div>
Thorsten Kukuk, Senior Architect SLES & Common Code Base<br>
SUSE LINUX GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany<br>
GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg)<br>
<div>
<div>_______________________________________________<br>
mkgmap-dev mailing list<br>
<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk" target="_blank">mkgmap-dev@lists.mkgmap.org.uk</a><br>
<a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div data-smartmail="gmail_signature">
<div dir="ltr">
<div>
<div dir="ltr">
<div>
<div>
<div>Felix Hartman - Openmtbmap.org & VeloMap.org<br>
</div>
Schusterbergweg 32/8<br>
</div>
<div>6020 Innsbruck<br>
</div>
</div>
Austria - Österreich</div>
</div>
</div>
</div>
</div>
</div>
</div></div></div>
<br>_______________________________________________<br>
mkgmap-dev mailing list<br>
<a href="mailto:mkgmap-dev@lists.mkgmap.org.uk">mkgmap-dev@lists.mkgmap.org.uk</a><br>
<a href="http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev" rel="noreferrer" target="_blank">http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev</a><br></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div><div>Felix Hartman - Openmtbmap.org & VeloMap.org<br></div>Schusterbergweg 32/8<br></div><div>6020 Innsbruck<br></div></div>Austria - Österreich</div></div></div></div>
</div>