<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 class="">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 class=""><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 class=""><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 class=""><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">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">mkgmap-dev-bounces@lists.mkgmap.org.uk</a>> im Auftrag von<br>
> > Felix Hartmann <<a href="mailto:extremecarver@gmail.com">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 class="">> ><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">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">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">mkgmap-dev-bounces@lists.mkgmap.org.uk</a>> im Auftrag<br>
> >>> von Felix Hartmann <<a href="mailto:extremecarver@gmail.com">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 class="h5">> >>><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">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">mkgmap-dev-bounces@lists.mkgmap.org.uk</a>> im Auftrag<br>
> >>>> von Felix Hartmann <<a href="mailto:extremecarver@gmail.com">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 class="h5">> >>>><br>
> >>>><br>
> >>>> On 27 July 2016 at 09:29, Gerd Petermann <<br>
> >>>> <a href="mailto:GPetermann_muenchen@hotmail.com">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">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">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">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">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 class="HOEnZb"><div class="h5">_______________________________________________<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>
</div></div></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>