Oh - check the Herreninsel Chieemsee. It was flooded based on 18.07 data and already flodded in June. Was fine in March though.
http://www.openstreetmap.org/way/4605746 It should be a multipolygon but it's not. It's much smaller than the lake however. Basically right now in my map the whole forest is flooded. Also Fraueninsel flooded. Mapnik get'r it right however! On 27 July 2016 at 14:52, Felix Hartmann <extremecar...@gmail.com> wrote: > Know - sadly not. Usually such places are fixed up sooner or later - and > then sometimes destroyed again. It's kinda hard to find them too - because > you will either give lake or water preference (or give it same > draw-priority and end up with chance). I just know since I implemented a > limited layer approach - complaints about something "missing" are much more > rare. > > On 27 July 2016 at 14:44, Gerd Petermann <gpetermann_muenc...@hotmail.com> > wrote: > >> Hi Felix, >> >> >> okay, I like the idea reg. layer, but I was not yet able to find an >> example in OSM. >> >> I assume the problem appears only in specific regions wheres such an >> unexperienced >> >> mapper is active. Do you know such a region? >> >> >> Gerd >> >> >> ------------------------------ >> *Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag >> von Felix Hartmann <extremecar...@gmail.com> >> *Gesendet:* Mittwoch, 27. Juli 2016 14:31:28 >> >> *An:* Development list for mkgmap >> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order >> >> Well the smaller polygon in usual is the one that people expect to end up >> on top. HOWEVER - before even checking for size - there could be a check >> for the layer tag. It is still commonly used by people who do not >> understand how to use multipolygons. >> >> So an approach could be - take polygon overlap check for values defined >> in "overlap" style-file - after multipolgyon overlap is gone. >> Check if layer tag is present on either of the polygons. If yes - then >> cut out according to layer. >> If not - cut out the smaller from the bigger. Usually it's the smaller >> polygon that should appear. >> >> I guess it needs to happen quite late therefore. Why smaller - well quite >> often people contacted me about islands missing/flooded or similar - and >> usually it was the smaller polygon that should have been on top. I guess >> with layer tag however 90% of all cases can already be resolved. (I do this >> in a very limited way already - by having some polygons like water and >> forest in several versions with different priority based on layer tag - >> this did help a lot) >> >> Felix >> >> On 27 July 2016 at 13:41, Gerd Petermann <gpetermann_muenc...@hotmail.com >> > wrote: >> >>> Hi Felix, >>> >>> >>> okay, maybe I'll add this as an experimental option as well. >>> >>> One big question here is: At what point would the cutting >>> >>> happen? Before style processing (as we do with mp-relations) >>> >>> or maybe as a new stage before the img data is written. >>> >>> >>> What I don't yet understand is the idea that a smaller >>> >>> polygon is more important. Do you have examples for that, >>> >>> esp. cases where shapes do only partially overlap? >>> >>> >>> Gerd >>> ------------------------------ >>> *Von:* mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag >>> von Felix Hartmann <extremecar...@gmail.com> >>> *Gesendet:* Mittwoch, 27. Juli 2016 13:24:37 >>> *An:* Development list for mkgmap >>> *Betreff:* Re: [mkgmap-dev] Option to output polygons in size order >>> >>> >>> On 27 July 2016 at 09:29, Gerd Petermann < >>> gpetermann_muenc...@hotmail.com> wrote: >>> >>>> reg. the idea of "cutting out overlaps": I guess it would consume quite >>>> a lot of CPU and it would heavily increase the img size >>>> >>>> because we would have to write many more points. Think of a shape for >>>> "place=village" with hundreds of holes for each building >>>> >>>> shape. Up to now we save the shape for the village and the shapes for >>>> the buildings. With cutting we have to calculate what >>>> >>>> remains of the village shape, this would be a very complex shape with >>>> many holes, so it would have many points. >>>> >>>> I don't think that would be a good idea. >>>> >>>> >>> Well that's why I wrote we will need an additional file in the >>> style-file for this. So only for certain polygons this should be done. >>> Prime examples are: any kind of forest, most kind of water, and maybe a >>> handful more. However definitely not buildings or for example poygons you >>> can put semi-transparent. >>> >>> I'm quite sure with this limited approach 90% of problems would be gone. >>> And mapsize only a couple percent bigger. However I have no clue about >>> complexity and CPU cycles for such a limited approach. >>> >>> >>> -- >>> Felix Hartman - Openmtbmap.org & VeloMap.org >>> Schusterbergweg 32/8 >>> 6020 Innsbruck >>> Austria - Österreich >>> >>> _______________________________________________ >>> mkgmap-dev mailing list >>> mkgmap-dev@lists.mkgmap.org.uk >>> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >>> >> >> >> >> -- >> Felix Hartman - Openmtbmap.org & VeloMap.org >> Schusterbergweg 32/8 >> 6020 Innsbruck >> Austria - Österreich >> >> _______________________________________________ >> mkgmap-dev mailing list >> mkgmap-dev@lists.mkgmap.org.uk >> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev >> > > > > -- > Felix Hartman - Openmtbmap.org & VeloMap.org > Schusterbergweg 32/8 > 6020 Innsbruck > Austria - Österreich > -- Felix Hartman - Openmtbmap.org & VeloMap.org Schusterbergweg 32/8 6020 Innsbruck Austria - Österreich
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
