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@.org
-- View this message in context: http://gis.19327.n5.nabble.com/A-few-thoughts-on-non-rectangular-tiles-tp582... Sent from the Mkgmap Development mailing list archive at Nabble.com.