Hi Felix, no problem. It is easy to verify the result of the new splitter, you can simply compare the output files, for "normal" data you should see no difference to r200. Gerd Felix Hartmann-2 wrote
ups, well I had checked for that. But somehow I had a tree conflict regarding external.properties file (which should exist anymore) and therefore wrong locations where it looked for the osmpbf.jar which didn't exist anymore. I'll write again once I can confirm whether the outcome is correctly working - but that will need some time as the data amount is huge....
On 04.04.2012 16:48, GerdP wrote:
Hi Felix,
I see those error messages when osmpbf.jar is missing. Do you try this in a different directory?
Gerd
Felix Hartmann-2 wrote
It's splitting the big data now, but for me all output is broken (even for files were the old splitter worked fine without probs):
Error at line 1, col 1 Bad file format: 75400000.osm.pbf Error parsing file ........ Error at line 1, col 1 Bad file format: 75400698.osm.pbf Error parsing file Exception in thread "main" java.lang.NullPointerException at uk.me.parabola.mkgmap.combiners.FileInfo.getFileInfo(FileInfo.java:139) at uk.me.parabola.mkgmap.main.Main.endOptions(Main.java:406) at uk.me.parabola.mkgmap.CommandArgsReader.readArgs(CommandArgsReader.java:126) at uk.me.parabola.mkgmap.main.Main.main(Main.java:112) openSUSE-121-64-minimal:/home/contourlines #
This also happens to srtm files. Have not tried standard osm.pbf extracts...
On 02.04.2012 10:35, GerdP wrote:
Hi Thorsten,
attached is a patch for the problem reported here:
http://gis.19327.n5.nabble.com/Bug-in-splitter-tp5610856p5610856.html
I don't have the data nor the machine to test it, so I tried to find all places were nodes are counted and changed the variables to long.
I did not find a good explanation for the small difference in the numbers: osmconvert reported 2518069911 nodes, which is ~ 2.518.069.911 -(2^31 - 1) = 370.586.264 - 2^31 + 370.586.264 =* -1.776.897.384* but splitter r200 reported * -1.776.905.107* nodes The formatting routine is not the reason. Any ideas?
Gerd
http://gis.19327.n5.nabble.com/file/n5611808/nodes_int_overflow_v1.patch nodes_int_overflow_v1.patch
-- View this message in context:http://gis.19327.n5.nabble.com/Patch-Overflow-in-splitter-node-counters-tp56... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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/Patch-Overflow-in-splitter-node-counters-tp56... Sent from the Mkgmap Development mailing list archive at Nabble.com. _______________________________________________ mkgmap-dev mailing list mkgmap-dev@.org http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
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/Patch-Overflow-in-splitter-node-counters-tp56... Sent from the Mkgmap Development mailing list archive at Nabble.com.