I was curious and coded the sort. The result was a bit surprising, because the change of the order
has an effect on the shapes. This is of course not wanted, the reason is that we set some flags on point objects which are shared by different shapes, depending on the order sometimes a flag is set by a previously processed shape. I think this is a bug and should be corrected first. I am not yet sure how, I think I tried to solve this problem before without success. For the experts: I am talking about the "preserved" flag which tells the Douglas-Peucker filter and other line simplification filters to keep a point. It is used for special nodes on roads and for shapes to "preserve horizontal and vertical lines" which are on the boundary of the shape. So, the flag is very important for routing and has an effect on shapes to avoid holes (e.g. white areas in the sea). I guess it would be better to use two different flags for the shapes and the routing nodes. Gerd ________________________________ Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk> im Auftrag von Felix Hartmann <extremecar...@gmail.com> Gesendet: Sonntag, 24. Juli 2016 21:40:47 An: Development list for mkgmap Betreff: Re: [mkgmap-dev] Option to output polygons in size order That is not really a good approach. Basecamp orders the polygons opposite to most gps devices. So it will still be broken. There is however a proper way to do - but that would be much much more complicated: Create a list of polygons that may not overlap (in the style-file). Then if mkgmap finds that 2 of these polygons do overlap - mkgmap should cut out the smaller polygon shape from the bigger. Basically the result of that approach would mimic how a Mapnik map looks in this case. Still the real solution however would be to fix the underlying OSM data. I have no clue how code and time intensive the "mimic Mapnik" approach would be, but everything else won't really solve much. On 24 July 2016 at 20:42, Gerd Petermann <gpetermann_muenc...@hotmail.com<mailto:gpetermann_muenc...@hotmail.com>> wrote: Hi Ticker, with the current algo the order is either "unpredictable" or the order in the input file (osm.pbf is typically sorted by id). This depends on the --preserve-element-order If I see this right this order will have an influence on the result of the so-called shape merger which tries to combine shapes with similar attributes. I still don't understand why the size should matter, but it should be easy to add a sort after the line shapes = mergedShapes; in MapBuilder.java I don't have the time today, so try on your own or wait a little for a patch . ________________________________ Von: mkgmap-dev <mkgmap-dev-boun...@lists.mkgmap.org.uk<mailto:mkgmap-dev-boun...@lists.mkgmap.org.uk>> im Auftrag von Ticker Berkin <rwb-mkg...@jagit.co.uk<mailto:rwb-mkg...@jagit.co.uk>> Gesendet: Sonntag, 24. Juli 2016 20:23:41 An: mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> Betreff: Re: [mkgmap-dev] Option to output polygons in size order Hi Gerd Looking at the meaning of the sub-division, this looks like just the place to try and order the polygons by size! What governs the order they appear in at the moment? The size should be the full size of the individual polygon. Concerning the new thread "Why do we render place=island polygons in the default style", I have used "place=island & size_of() < 1000000" to get around the major problem but it seemed a bit arbitrary, and when I found other examples where, just sometimes, large polygons mask all features within I thought there must be a more general solution Ticker On Sun, 2016-07-24 at 00:05 -0700<tel:05%20-0700>, Gerd Petermann wrote: > Hi Ticker, > > Ticker Berkin wrote > > I'd understood and hoped that, for areas with the same level it > > rendered areas in file order, and I see on my device it > > overwriting, > > sometimes woods with island, sometimes the other way around, > > depending > > on, I presumed, the input ordering. I see the exactly the same > > overwriting effect zooming in or scrolling in any direction. > > > > What is the scale of the 'sub areas' you mention? > > I should have said sub division , and they have no specific scale. > They are used to group nearby elements, and they have several limits > like "not more than 255 points and not more than 255 lines in one sub > div" > For details see first the imgformat-1.0.pdf from Mechalas: > http://sourceforge.net/projects/garmin-img/files/OldFiles/imgformat.p > df/download > Other sources: > http://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/IMG_File_Format > (which has more links at the end) > > Reg. the British Islands polygon: If I got that right this is the > very complex mp-relation > https://www.openstreetmap.org/relation/6038068 > (don't use the link, the thing is too complex) > It was added 2016-03-09 so maybe the problem is rather new and nobody > noticed it. I think it makes no sense to render that polygon, the > rules > in the default style should be changed to check the > area_size() for place=island so that large polygons are ignored. > I'll try to find a reasonable value. > > Gerd > > > > > > > -- > View this message in context: http://gis.19327.n5.nabble.com/Option-t > o-output-polygons-in-size-order-tp5878989p5879011.html > Sent from the Mkgmap Development mailing list archive at Nabble.com. > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto:mkgmap-dev@lists.mkgmap.org.uk> http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk<mailto: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
