Hi Here are a few thoughts on non-rectangular tiles. The main problem is knowing where to start really. The Files --------- I looked into this a few years ago and I don't think that there is anything fundamentally different about producing non-rectangular tiles. It is normal to split tiles at land based country borders, so that the tile follows the border exactly. For countries separated by sea, such as Sweden and Finland straight lines can often be used without regard to the alignment that we currently use. - You just create a tile with an arbitrary shape, the background polygon if any follows the shape. - The TRE section still records the bounding box of the tile. - the TDB file still contains those rectangular bounding boxes and so they will, in general, overlap. - You add add the actual shape of the tile as a 'map selection area' to the overview map. So we need to allow an arbitrary polygon as background in mkgmap. Splitting --------- The majority of tiles would remain rectangular as they at present. 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. I think that the bounds file (or some similar purpose built file) should be used. There is no need to split along coastal boundaries. Only if a tile would reach to another country does it need to be split. When splitter creates the tiles, the actual boundary of a tile needs to be communicated to mkgmap in some way. Implementation -------------- Currently we have restrictions on the alignment of tile boundaries, these can all go, as this is a constraint to make things easier for us and not a feature of the format. There will probably be a few things to fix up so that the tiles still meet and route without gaps. I would suggest starting out with one tile cut in two with a sloping line. If we can get that to work without routing problems or visible gaps across all zoom levels, then most of the problems should be sorted out before putting in the work to support completely arbitrary boundaries. Then we add a more complex background polygon. ..Steve
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
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.
El 11/12/14 a las 11:20, GerdP escribió:
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. *.poly files may contain polygon name before the list of coordinates. For example: |cuba|| ||1|| || -85.08 23.55|| || -78.68 23.55|| || -73.46 20.40|| || -73.84 19.73|| || -77.76 19.01|| || -79.26 20.23|| || -85.12 21.27|| || -85.08 23.55|| ||END|| ||END|
Hi Carlos, yes, you are right, and splitter is using it. I thought the missing name was the reason for the introduction of the polygon-desc-file parameter in splitter, but in fact it was the possibility to define multiple areas with different names, and I think that is not possible with the *.poly format. After writing my previous post I thought it would also be a good thing to extract an area from the bounds files. The advantage would be that we don't have to mess with different areas in the boundaries and a polygon file, but I am not sure that the existing format allows that, as it is optimized for the LocationHook. Gerd
Date: Fri, 19 Dec 2014 11:07:24 +0100 From: cdavilam@orangecorreo.es To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] A few thoughts on non-rectangular tiles
El 11/12/14 a las 11:20, GerdP escribió:
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. *.poly files may contain polygon name before the list of coordinates. For example: |cuba|| ||1|| || -85.08 23.55|| || -78.68 23.55|| || -73.46 20.40|| || -73.84 19.73|| || -77.76 19.01|| || -79.26 20.23|| || -85.12 21.27|| || -85.08 23.55|| ||END|| ||END|
mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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
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
-- 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.
Hi Gerd, there are some tasks, which splitter could automatize. But I'm more interested in getting a working map than optimizing workflow. That's why I ask to start with mkgmap ;) -- Best regards, Andrzej
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi Gerd, I would suggest that a common osm-file format would be the easiest way for most of the users (who generating maps out of osm-data and are used to josm). The next question is: Should there only be a non-rectangular border of the hole map or for each tile? Eg. If I want to have a map of Germany with the shape of Germany and also tiles shaping the federal states (Bundesländer), it would be necessary to tell splitter or mkgmap in the end what is outside border and which borders are inside the map. Or am I wrong? Henning -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (MingW32) iQEcBAEBAgAGBQJUlUzWAAoJEKXggIeC16WP+18IAOIvzYYLV+G7d5cW9500uKpf CSY8EGRtL5JTfjIC/8hXdO5JzIMQhjBKxXNfkzrCQLZCBLqKlvisdDtaI18UcL9i JtaVP0Q55O7kdmIdQVPoE0J1CASKOfMjnscECmv7wpeWgv31dD/pJjCn/KC0shRj tIkCQogGN1k82B6KzitCv8xZVjyGpNlS6CbWlpX7oSxMN63mSmzXkmuZ12F5Usi6 HUyLwMZ2F52TuQZTSpZGH9+y8Y7FuXy/giI+YTqGY8rFJSKUaWcI4AgtTlt9FWZq PMdNRSSCvhIFUDn1SMS4WP3nZBeSy7FYiMaMt0xez/3XUW55bQEbYa3JfnOs9ik= =VOWf -----END PGP SIGNATURE-----
Hi Henning,
I would suggest that a common osm-file format would be the easiest way for most of the users (who generating maps out of osm-data and are used to josm).
The next question is: Should there only be a non-rectangular border of the hole map or for each tile?
Eg. If I want to have a map of Germany with the shape of Germany and also tiles shaping the federal states (Bundesländer), it would be necessary to tell splitter or mkgmap in the end what is outside border and which borders are inside the map. Or am I wrong?
I think that depends on how well the routing works at the borders. You may start building the tiles for the Bundesländer and combine them to Germany, if that works well. Gerd
participants (6)
-
Andrzej Popowski -
Carlos Dávila -
Gerd Petermann -
GerdP
-
Henning Scholland -
Steve Ratcliffe