Hi Andrzej, as I wrote before I see no need to change splitter. Even if we would be able to store and calculate the exact shape of each element within splitter, we would have to write data outside of the polygon so that ways etc. are complete. So, the only improvement would be a reduction of file sizes. On the other hand, we will still need the same routines in mkgmap, as it should be able to process data that was not written by splitter.
Gerd popej wrote > Hi Gerd, > > what about a simple solution, that could be used for tests? > > I mean to add a support for bounding poly to mkgmap as an input option, > for example: > --bounding-poly=12345678.poly > > With this option mkgmap could define tile area as a common area of a > polygon and bounding box inside osm data. > > I think this could be used in template.args too, if splitter prepares > polygons for each tile. > > And we could create polygons manually for testing maps, even if splitter > doesn't support polygons yet. > > -- > Best regards, > Andrzej > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev@.org > http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev -- View this message in context: http://gis.19327.n5.nabble.com/A-few-thoughts-on-non-rectangular-tiles-tp5825948p5827748.html Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
