Map generation: Reduce required disc space

General talk
1

Presently, I am generating maps for my Garmin eTrex Vista Hcx with the following script:



d:
cd \map
wget http://download.geofabrik.de/osm/europe.osm.bz2

7za e -y d:\map\europe.osm.bz2

java -Xmx1600m -cp .\Osmosis\osmosis.jar;.\Osmosis\lib\default\commons-logging-1.1.1.jar;.\Osmosis\lib\default\commons-compress-1.0.jar;.\Osmosis\lib\default\jpf-1.5.jar org.openstreetmap.osmosis.core.Osmosis --read-xml file="europe.osm" --bounding-box idTrackerType=BitSet top=60 left=4 bottom=47 right=16 --write-xml file="Centraleurope.osm"

java -Xmx1600m -jar splitter.jar --max-nodes=600000 Centraleurope.osm

java -Xmx1600m -jar mkgmap.jar --max-jobs --reduce-point-density=10 --description=OSM_DE --country-name=centraleurope --country-abbr=EU --name-tag-list="name:de,name,int_name" --style-file=.\My_Style\ --generate-sea=multipolygon --family-id=1331 --product-id=1 --series-name=OSM_Germany --family-name=OSM_Germany --area-name=Germany --overview-mapname=OSM_Centraleurope --net --gmapsupp --tdbfile --route --add-pois-to-areas --road-name-pois=0x640a --draw-priority=25 --latin1 --make-opposite-cycleways --remove-short-arcs -c template.args My.typ
pause

It works fine and produces a map of germany with some surrounding areas, but it needs about 140 GByte of free harddisc space. The main reason is, that the unpacked file europe.osm has almost 100 GByte in size.

Is there a trick to reduce the necessary disc space, e. g. by letting osmosis access the europe.osm.bz2 file directly?

2

Why don’t you just split the europe.osm.bz2 file directly?

3

You could use the PBF format extracts from Geofabrik, they use less disc space than the bz2 files.
Osmosis can read or write in PBF format, and splitter/mkgmap can read from them.

4

Thank you very much for this hint!
I now exchanged the *.osm files by *.osm.bz2 and removed the unzip command:


d:
cd \map
rem wget http://download.geofabrik.de/osm/europe.osm.bz2

java -Xmx1600m -cp .\Osmosis\osmosis.jar;.\Osmosis\lib\default\commons-logging-1.1.1.jar;.\Osmosis\lib\default\commons-compress-1.0.jar;.\Osmosis\lib\default\jpf-1.5.jar org.openstreetmap.osmosis.core.Osmosis --read-xml file="europe.osm.bz2" --bounding-box idTrackerType=BitSet top=60 left=4 bottom=47 right=16 --write-xml file="Centraleurope.osm.bz2"

java -Xmx1600m -jar splitter.jar --max-nodes=600000 Centraleurope.osm.bz2

java -Xmx1600m -jar mkgmap.jar --max-jobs --reduce-point-density=10 --description=OSM_DE --country-name=centraleurope --country-abbr=EU --name-tag-list="name:de,name,int_name" --style-file=.\My_Style\ --generate-sea=multipolygon --family-id=1331 --product-id=1 --series-name=OSM_Germany --family-name=OSM_Germany --area-name=Germany --overview-mapname=OSM_Centraleurope --net --gmapsupp --tdbfile --route --add-pois-to-areas --road-name-pois=0x640a --draw-priority=25 --latin1 --make-opposite-cycleways --remove-short-arcs -c template.args My.typ
pause

This needed only a few GBytes of drive space. A drawback is, that it took much more time (about 17 hours on my computer compared to an approximate “overnight job” before). Can I somehow use the second core of the CPU also for Osmosis? The resulting gmapsupp.img seemed to be ok, as a first test with my garmin indicated.

What I don’t understand is: Both gmapsupp.img-files have the same length, but are not equal on a binary level.