Re: [mkgmap-dev] Splitter doesn't process pbf data created with osmosis 0.39
On Mon, 19 Sep 2011 20:03:20 +0200, Thorsten Kukuk wrote:
On Mon, Sep 19, Michael Prinzing wrote:
there seems to be a problem with the latest splitter and data in pbf format if it was created with osmosis 0.39.
When I am converting a xml file to pbf by callig osmosis 0.39 just with --read-xml and --write pbf parameters, the splitter (called without parameters) says:
------------------------------------------------ Processing data_039.osm.pbf Bounding box 0.0 0.0 0.0 0.0 in 1 file Time: Sun Sep 18 15:45:48 CEST 2011 Exact map coverage is (0.0,0.0) to (2.1457672119140625E-5,2.1457672119140625E-5) Trimmed and rounded map coverage is (0.0,0.0) to (2.1457672119140625E-5,2.1457672119140625E-5) Splitting nodes into areas containing a maximum of 1.600.000 nodes each... 0 areas: ------------------------------------------------ [...] Is this an issue with osmosis 0.39 or with the splitter?
Works fine for me. Could it be that the bounding box of your input data is not correct?
I don't think so. I've tried with data saved from josm (with the bounding box set correctly) and with other data without a bounding box at all. And the same input data is working if it is converted with osmosis 0.38. I am running the binary distribution of osmosis under Windows XP with Java 1.7. This should not be the problem since it is working with osmosis 0.38, but anyway: what was the environment in which you've tested successfully, and did you compile the source or use the precompiled binary? Michael
On Mon, Sep 19, Michael Prinzing wrote:
I am running the binary distribution of osmosis under Windows XP with Java 1.7. This should not be the problem since it is working with osmosis 0.38, but anyway: what was the environment in which you've tested successfully, and did you compile the source or use the precompiled binary?
I'm using IBM Java 1.6.0 sr9.2 or SUN Java 1.6.0.u23 on Linux/x86_64. The input are several gigabyte big files produced by phyghtmap, converted by a script with grep/sed to a v0.6 osm file and then with osmosis 0.39 to osm.pbf to save disk space. I'm using the precompiled splitter jar file. Thorsten -- Thorsten Kukuk, Project Manager/Release Manager SLES SUSE LINUX Products GmbH, Maxfeldstr. 5, D-90409 Nuernberg GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 16746 (AG Nürnberg)
El 19/09/11 23:16, Michael Prinzing escribió:
On Mon, 19 Sep 2011 20:03:20 +0200, Thorsten Kukuk wrote:
On Mon, Sep 19, Michael Prinzing wrote:
there seems to be a problem with the latest splitter and data in pbf format if it was created with osmosis 0.39.
When I am converting a xml file to pbf by callig osmosis 0.39 just with --read-xml and --write pbf parameters, the splitter (called without parameters) says:
------------------------------------------------ Processing data_039.osm.pbf Bounding box 0.0 0.0 0.0 0.0 in 1 file Time: Sun Sep 18 15:45:48 CEST 2011 Exact map coverage is (0.0,0.0) to (2.1457672119140625E-5,2.1457672119140625E-5) Trimmed and rounded map coverage is (0.0,0.0) to (2.1457672119140625E-5,2.1457672119140625E-5) Splitting nodes into areas containing a maximum of 1.600.000 nodes each... 0 areas: ------------------------------------------------ I confirm I've had the same problem after cutting data from Srtm2Osm with osmosis 0.39 [1] and passing it to latest splitter [2]. Didn't test with osmosis 0.38 though. debian testing i386 java version "1.6.0_26" Java(TM) SE Runtime Environment (build 1.6.0_26-b03) Java HotSpot(TM) Server VM (build 20.1-b02, mixed mode)
[1] osmosis --rx enableDateParsing=no srtm.osm --bounding-polygon file="spain.poly" --wb srtm_spain.osm.pbf omitmetadata=true [2] java -Xmx2500M -jar splitter.jar --mapid=65140001 --mixed=true --max-nodes=7500000 --description="SRTM Spain" srtm_spain.osm.pbf
[...]
Is this an issue with osmosis 0.39 or with the splitter? Works fine for me. Could it be that the bounding box of your input data is not correct? I don't think so. I've tried with data saved from josm (with the bounding box set correctly) and with other data without a bounding box at all. And the same input data is working if it is converted with osmosis 0.38.
I am running the binary distribution of osmosis under Windows XP with Java 1.7. This should not be the problem since it is working with osmosis 0.38, but anyway: what was the environment in which you've tested successfully, and did you compile the source or use the precompiled binary?
Michael
_______________________________________________ mkgmap-dev mailing list mkgmap-dev@lists.mkgmap.org.uk http://www.mkgmap.org.uk/mailman/listinfo/mkgmap-dev
-- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx Instale LibreOffice desde http://es.libreoffice.org/descarga/ LibreOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. LibreOffice está en continuo desarrollo y no tendrá que pagar por las nuevas versiones.
participants (3)
-
Carlos Dávila -
Michael Prinzing -
Thorsten Kukuk