splitter-r269 - problems with osm-data and srtm-data
Hi, I've got some problems with actual splitter and a combined input of osm and srtm-data. I merged them with osmconvert, so I think they are not mixed(--mixed gave the same result as without --mixed). I use splitter with an polygon-file of New Zealand [1] and max-nodes=1000000, which is no problem if I use only osm-data as input. Splitter generates thefollowing density-map [2] and then ends with the message: Failed to calculate areas. Sorry. Cannot split the file without creating huge, almost empty, tiles. Please specify a bounding polygon with --polygon-file parameter. Tiles should get smaller with srtm data, so my guess would bethat the tiles, which covers parts of the sea could be problematic.If you need further information, let me know. Henning [1] http://www.aighes.de/data/NewZealand.poly [2] http://www.aighes.de/data/densities-out.zip
Hello Henning, I did not yet look closer at this, but I guess the reason is that the srtm data increases the nodes for a tile so that splitter has to split it. After that, probably, one small tile contains almost all nodes and the other large one only a few. Maybe it helps if you use a slightly higher max-nodes value. Gerd Henning Scholland wrote
Hi, I've got some problems with actual splitter and a combined input of osm and srtm-data. I merged them with osmconvert, so I think they are not mixed(--mixed gave the same result as without --mixed).
I use splitter with an polygon-file of New Zealand [1] and max-nodes=1000000, which is no problem if I use only osm-data as input. Splitter generates thefollowing density-map [2] and then ends with the message:
Failed to calculate areas. Sorry. Cannot split the file without creating huge, almost empty, tiles. Please specify a bounding polygon with --polygon-file parameter.
Tiles should get smaller with srtm data, so my guess would bethat the tiles, which covers parts of the sea could be problematic.If you need further information, let me know.
Henning
[1] http://www.aighes.de/data/NewZealand.poly [2] http://www.aighes.de/data/densities-out.zip
_______________________________________________ mkgmap-dev mailing list
mkgmap-dev@.org
-- View this message in context: http://gis.19327.n5.nabble.com/splitter-r269-problems-with-osm-data-and-srtm... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Am 22.12.2012 13:26, schrieb GerdP:
Hello Henning,
I did not yet look closer at this, but I guess the reason is that the srtm data increases the nodes for a tile so that splitter has to split it. After that, probably, one small tile contains almost all nodes and the other large one only a few. Maybe it helps if you use a slightly higher max-nodes value. Hi Gerd, I tried NewZealand also with 1.500.000 and 2.000.000 as max-nodes. Both failed. Germany and the alps were fine with 1.000.000. Turkey same as NewZealand. I tried NewZealand with r202 (cut polygon with osmconvert before) and it works fine with 1.000.000.
So I think there is a problem with larger water-parts and many nodes with your new algorithm. Henning
Henning Scholland wrote
Hi Gerd, I tried NewZealand also with 1.500.000 and 2.000.000 as max-nodes. Both failed. Germany and the alps were fine with 1.000.000. Turkey same as NewZealand. I tried NewZealand with r202 (cut polygon with osmconvert before) and it works fine with 1.000.000.
So I think there is a problem with larger water-parts and many nodes with your new algorithm.
I tried to reproduce the problem with the data in http://www.aighes.de/data/densities-out.zip, but that seems to be the output of a different area? Or maybe the explanation for the problem is that your merge with osmconvert produces a file with a strange bbox. When I cut planet with your newzealand.poly I have no problems and I get a densities-out.txt that starts with two lines giving "planet" bboxes: -4194304,-8388608,4194304,8388608 -4194304,-8388608,4194304,8388608 In your densities-out.txt I find this -4194304,-8388608,4194304,8388608 2027520,227328,2568191,800768 The 2nd bbox comes from the input file, and it doesn't cover anything near New Zealand. Splitter reports Exact map coverage is (43.505859375,4.8779296875) to (55.10740041732788,17.1826171875) Is it possible that the srtm data doesn't cover planet and osmconvert puts only this smaller bbox into the merged file? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r269-problems-with-osm-data-and-srtm... Sent from the Mkgmap Development mailing list archive at Nabble.com.
Hello Henning, Markus Weber, the author of osmconvert, has changed the program so that it now merges the bboxes of multiple input files. Please use version 0.7M or higher. Ciao, Gerd
Date: Sun, 23 Dec 2012 00:28:18 -0800 From: gpetermann_muenchen@hotmail.com To: mkgmap-dev@lists.mkgmap.org.uk Subject: Re: [mkgmap-dev] splitter-r269 - problems with osm-data and srtm-data
Henning Scholland wrote
Hi Gerd, I tried NewZealand also with 1.500.000 and 2.000.000 as max-nodes. Both failed. Germany and the alps were fine with 1.000.000. Turkey same as NewZealand. I tried NewZealand with r202 (cut polygon with osmconvert before) and it works fine with 1.000.000.
So I think there is a problem with larger water-parts and many nodes with your new algorithm.
I tried to reproduce the problem with the data in http://www.aighes.de/data/densities-out.zip, but that seems to be the output of a different area? Or maybe the explanation for the problem is that your merge with osmconvert produces a file with a strange bbox. When I cut planet with your newzealand.poly I have no problems and I get a densities-out.txt that starts with two lines giving "planet" bboxes: -4194304,-8388608,4194304,8388608 -4194304,-8388608,4194304,8388608
In your densities-out.txt I find this -4194304,-8388608,4194304,8388608 2027520,227328,2568191,800768
The 2nd bbox comes from the input file, and it doesn't cover anything near New Zealand. Splitter reports Exact map coverage is (43.505859375,4.8779296875) to (55.10740041732788,17.1826171875)
Is it possible that the srtm data doesn't cover planet and osmconvert puts only this smaller bbox into the merged file?
Gerd
-- View this message in context: http://gis.19327.n5.nabble.com/splitter-r269-problems-with-osm-data-and-srtm... 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
Hi Gerd, thanks for your information. I played a little bit with osmconvert and found out, that bbox was taken from the first input-file. So if I put planet.o5m to first position and it works again. But this is now obsolet. Henning
Henning Scholland wrote
Hi Gerd, thanks for your information. I played a little bit with osmconvert and found out, that bbox was taken from the first input-file. So if I put planet.o5m to first position and it works again. But this is now obsolet.
I think one problem remains: If you feed splitter with a polygon file for New Zealand and OSM data for eg. norway splitter will fail without a proper error message. In this example it is obvious that splitter should stop with an error message, but what should happen if you use eg. your DACH.poly together with just germany.osm.pbf? I think whenever the bounding box of the input file doesn't intersect with the bounding polygon splitter should stop with an error message, anything else might be wanted. OK? Gerd -- View this message in context: http://gis.19327.n5.nabble.com/splitter-r269-problems-with-osm-data-and-srtm... Sent from the Mkgmap Development mailing list archive at Nabble.com.
participants (3)
-
Gerd Petermann -
GerdP
-
Henning Scholland