Ah, I begin to understand. With a few polygons of test data (which might fit into a single sub division), changing order in the input had the desired effect on the drawing order. But with bigger input the results were somehow random.
I hope a practical way can be found to deal with this problem. If one could specify a layer or priority value for several tags within the style file, maybe mkgmap could collect polygons of equal priority in different sub divisions and sort the whole sub divisions in corresponding order. If it would be necessary to break the map into areas that fit into sub divisions, this could be made optional just for marine maps which do not support routing anyway. Maybe it´s easier without the routing stuff. > -----Ursprüngliche Nachricht----- > Von: mkgmap-dev-boun...@lists.mkgmap.org.uk [mailto:mkgmap-dev- > boun...@lists.mkgmap.org.uk] Im Auftrag von GerdP > Gesendet: Dienstag, 12. März 2013 11:24 > An: mkgmap-dev@lists.mkgmap.org.uk > Betreff: Re: [mkgmap-dev] Splitter Error > > RheinSkipper wrote > > I want to establish the order I need via a preprocessing. This > > preprocessor (programmed by Malcolm) is already working perfectly. > > > > All I need from mkgmap is not to mix up this order. > > OK, that is understood. With --preserve-element-order and mkgmap >= > r2507 the order is not mixed in the program, means, two executions of the > program with the same input should give the same output (besides some > time stamp values in the img file). > The problem remains: The garmin img format is not flat, it requires us to > build > sub divisions with a lot of restrictions regarding the size and number of > elements in it. > Thus, two polygons maybe be placed in the same sub division or not. > > I see only one possible solution: We could change the algo that creates sub > divisions completely so that we first calculate the subdiv rectangle, next > place > all objects into it. If that rectangle doesn't fullfil the restrictions, > divide it into > two or more rectangles and place all objects into the parts by cutting > anything that is not completely within the smaller rectangle. > The current algo doesn't cut anything, so this change will probably require a > lot more time and spcecial routines to care about routing and rounding errors > caused by the cutting. > > I don't know if that was already tried before? > > Gerd > > > > > > -- > View this message in context: http://gis.19327.n5.nabble.com/Splitter-Error- > tp5752745p5752909.html > Sent from the Mkgmap Development mailing list archive at Nabble.com. > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev@lists.mkgmap.org.uk > http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://lists.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
