[mkgmap-dev] A few thoughts on non-rectangular tilesFrom GerdP gpetermann_muenchen at hotmail.com on Thu Dec 11 10:20:58 GMT 2014
Hi Steve, If I got it right, we need these changes: 1) an option to pass the polgon(s) to mkgmap. I don't know which format is good for this. In splitter we use the OSM (xml, o5m, pbf) format to pass named polygons (with --polygon-desc-file) or the *.poly format (with --polygon-file ) from osmosis which doesn't allow named polygons. I think it would be good to have a file containing the country borders so that one can use options like --polygon-desc-file in combination with an include/exclude list e.g. --include-countries=abc,xyz and --exclude-countries=... Another useful option woud be to have groups, e.g. all drive-on-left countries. 2) A class to store the intersection of the tile bbox and the polygon(s) which also implements the Clipper interface and maybe more. I call it PolygonClipper for now. If performace matters, we can implement a spatial index here. 3) All classes that use the tile bbox, e.g. the hooks like SeeGenerator, UnusedElementsRemoverHook, LocationHook etc. have to use the PolygonClipper methods instead of a check against the bbox. Esp. we have to make sure that the boundary nodes are okay. 4) The classes implementing Clipper should use the PolygonClipper (or they are replaced by it) I think we can split the work so that one implements the user interface for the polygon handling and one implements the clipping algos. Do you see anything else to do? Gerd GerdP wrote > Hi Steve, > >> Tiles that would contain a land border need to be further split >> along that border. This could be done >> 1. Directly by splitter >> 2. By running mkgmap once for each country. >> 3. Some intermediate process. >> >> I believe it would be best in the long term for splitter to make the >> split, but perhaps the other strategies could be used temporarily in >> order to concentrate on other parts of the process. > > Up to now I see no need to change splitter. > We already have the UnusedElementsRemoverHook, > I would try to add a similar method to > filter data which is outside of a given polygon. > Depending on the complexity of the polygon > this can be quite time consuming for just on tile. > If we try to do that in splitter and try to split e.g. > Europe, we have to store a lot of complex polygons > as we try to process many tiles at once. > I see only one possible advantage when doing it > in splitter: > A perfect algo would be able to make sure that > all tiles for one country have a similar number of > nodes. When we use mkgmap for filtering a > single rectangular tile might just overlap a country > in a very small area, thus the resulting *.img would > be very small. > > Gerd > > > _______________________________________________ > mkgmap-dev mailing list > mkgmap-dev at .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-tp5825948p5826912.html Sent from the Mkgmap Development mailing list archive at Nabble.com.
- Previous message: [mkgmap-dev] A few thoughts on non-rectangular tiles
- Next message: [mkgmap-dev] A few thoughts on non-rectangular tiles
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the mkgmap-dev mailing list