Splitten von .osm Datei funktioniert nicht

Splitten von .osm Datei funktioniert nicht

Was hab ich vor :
Ich erstelle eine Karte im Format .img
Vorgehensweise ist aus den Daten der Geofabrik wird einen Bereich ausgeschnitten und eine Karte erstelle , das funktioniert auch. Das Ausschneiden der Karte und Höhendaten werden durch die gleiche Koordinaten definiert.
Das Erstellen der Katen .img funktioniert !

Das Problem sind die Höhen .img zu erzeugen.
Mit diesen Befehl lade ich die entsprechenden Höhendaten runder endsprechen der vorgegeben Koordinaten das auch funktioniert :

Beispiel das nicht funktioniert:
Höhendaten laden, Größe der erzeugten .osm 965 MB
srtm2osm -bounds1 49.3 9.6 50.7 11.7 -cat 500 100 -step 10 -o C:\MyOsmTopo\Kartenprojekt_MyOsmTopo-test-karte-gross\Hoehendaten_MyOsmTopo-test-karte-gross.osm

Splitten
java -Xmx1000M -jar C:\MyOsmTopo\KARTEN-BAU\TOOLS\splitter\splitter.jar --mapid=90013001 --overlap=8000 --description=MyOsmTopo-test-karte-gross --max-nodes=2500000 C:\MyOsmTopo\Kartenprojekt_MyOsmTopo-test-karte-gross\Hoehendaten_MyOsmTopo-test-karte-gross.osm

Das splitte der erzeugte Hoehendaten_MyOsmTopo-test-karte-gross.osm ,funktioniert aber nicht ,die xxxx.img werden nicht erstellt! !

Wenn ich aber eine kleinere Kartenbereich ausschneide funktioniert es !

Beispiel das funktioniert :

Höhendaten laden, Größe der erzeugten .osm 48 MB
srtm2osm -bounds1 49.8 10.3 50.1 10.9 -cat 500 100 -step 10 -o C:\MyOsmTopo\Kartenprojekt_MyOsmTopo-test-karte-klein\Hoehendaten_MyOsmTopo-test-karte-klein.osm

Splitten

splitter.jar --mapid=90013001 --overlap=8000 --description=MyOsmTopo-test-karte-klein --max-nodes=2500000 C:\MyOsmTopo\Kartenprojekt_MyOsmTopo-test-karte-klein\Hoehendaten_MyOsmTopo-test-karte-klein.osm

Das splitten der erzeugte Hoehendaten_MyOsmTopo-test-karte-klein.osm , das funktioniert in diesen Fall, die xxxx.img werden erstellt!

wo könnte da der Fehler liegen ?
Bei einen kleineren Bereich von Höhendaten .osm erzeugt mit srtm2osm funktioniert das splitten, sobald der Bereich größer wird funktioniert es nicht mehr die .osm zu splitten .
Die Befehlssätze sind doch jeweils gleich nur die Größe der jeweils erzeugten .osm die gesplittet werden soll sind unersichtlich groß !

Hat jemand eine Rat ?

gruss

Schau mal, ob Dir der Abschnitt Garmin im Wiki weiterhilft: https://wiki.openstreetmap.org/wiki/Srtm2Osm#Garmin

Das hab ich schon angesehen , da gibt es auch was für große Kartenbereiche , aber ich hab da noch nicht genügen Wissen um das genau zu analysieren .

Es kann ja eigentlich nur daran liegen das die erzeugte Hoehendaten_MyOsmTopo-test-karte-gross.osm zu groß ist oder am Splitter.
Wie machen es andre die zum Beispiel Höhen Daten von ganz Deutschland erzeugen und Splitten ?

Nur die große Hoehendaten_MyOsmTopo-test-karte-gross.osm 965 MB macht beim Splitten Probleme ! Da werden die .img der Höhendaten nicht erzeugt folglich fehlen Höhenlinien in der karte .
Das splitten der Hoehendaten_MyOsmTopo-test-karte-klein.osm 48 MB funktioniert ! Da werden die .img der Höhenlinen erzeugt ,die Karte wird komplett mit Höhenlinien erstellt

die Befehle bei beiden Varianten sind doch jeweils in ihrer Struktur absolut gleich ?

gruss

Weil du das jetzt zum zweiten mal schreibst: der Splitter erzeugt keine .img-Datei sondern mehrere .osm- bzw .obf-Dateien. Was passiert denn bei dem Splitter-Auruf, kommt eine Fehlermeldung, werden .osm/.obf-Dateien erzeugt? Hast du schon mal den max-nodes-Wert reduziert?

Was willst Du denn da noch analysieren? Einfach mal die Parameter
-maxwaynodes 5000 -firstnodeid 9023372036854775807 -firstwayid 9023372036854775807
verwenden und schauen, ob es hilft.
Ansonsten bekommst Du aus splitter erst mal keine *.img Dateien, die werden von mkgmap erzeugt. Wenn das schiefgeht, dann solltest Du irgendwelche Fehlermeldungen bekommen. Ohne die ist es für uns schwer, Dir zu helfen.

Du hast ja recht , der Splitter liefert keine .img sondern .pbf Dateien , das hab ich aber auch so gemeint .

Hier mal den Inhalt des cmd beim splitten der mit .srtm2osm erzeugten Hoehendaten_MyOsmTopo-test-karte-gross.osm 965 MB. die .osm wurde mit den Original Befehlssatz erzeugt , also ich hab erst mal keine Änderungen am srtm2osm Befehlssatz vorgenommen und dann den Splitter laufen lassen .

Splitter cmd Text, endlich ist es mir gelungen den Inhalt des cmd zu kopieren !

Befehlssatz zum Splitten
splitter.jar --mapid=90013001 --overlap=8000 --description=MyOsmTopo-test-karte-klein --max-nodes=2500000 C:\MyOsmTopo\Kartenprojekt_MyOsmTopo-test-karte-klein\Hoehendaten_MyOsmTopo-test-karte-klein.osm

Cmd-Text

SPLITTEN der HOEHEN-DATEN mit SPLITTER
Die Datei Hoehendaten_MyOsmTopo-test-karte-gross.osm wird in kleinere Teile fuer die Weiterverarbeitung zerteilt.

Zum Starten -
Drücken Sie eine beliebige Taste . . .

. . . Splitter arbeitet . . .
Splitter version 592 compiled 2018-12-13T08:19:25+0000
boundary-tags=use-exclude-list
cache=
description=MyOsmTopo-test-karte-gross
geonames-file=
handle-element-version=remove
ignore-osm-bounds=false
keep-complete=true
mapid=90013001
max-areas=2048
max-nodes=2500000
max-threads=8 (auto)
mixed=false
no-trim=false
num-tiles=
output=pbf
output-dir=
overlap=8000
polygon-desc-file=
polygon-file=
precomp-sea=
problem-file=
problem-report=
resolution=13
route-rel-values=
search-limit=200000
split-file=
status-freq=120
stop-after=dist
wanted-admin-level=5
write-kml=
Warning: --overlap is used in combination with --keep-complete=true
The option keep-complete should be used with overlap=0 because it is very unlikely that
the overlap will add any important data. It will just cause a lot of additional output which
has to be thrown away again in mkgmap.
Elapsed time: 0s Memory: Current 15MB (3MB used, 12MB free) Max 966MB
Time started: Sat Jan 19 10:37:07 CET 2019
Map is being split for resolution 13:

  • area boundaries are aligned to 0x800 map units (0.0439453125 degrees)
  • areas are multiples of 0x800 map units wide and high
    Processing C:\MyOsmTopo\Kartenprojekt_MyOsmTopo-test-karte-gross\Hoehendaten_MyOsmTopo-test-karte-gross.osm
    Fill-densities-map pass took 21971 ms
    Exact map coverage read from input file(s) is (49.30041790008545,9.600419998168945) to (50.70042371749878,11.70041799545288)
    Rounded map coverage is (49.2626953125,9.580078125) to (50.712890625,11.7333984375)
    Splitting nodes into areas containing a maximum of 2.500.000 nodes each…
    Highest node count in a single grid element is 8.195
    Solving partition (49.2626953125,9.580078125) to (50.712890625,11.7333984375) with 4.084.624 nodes
    Trying to find nice split for (49.2626953125,9.580078125) to (50.712890625,11.7333984375) with 4.084.624 nodes
    searching for split with min-nodes 125000, learned 0 good partial solutions
    Best solution until now: 2 tile(s). The smallest node count is 1668380 (66 %), the worst aspect ratio is near 1.97, elapsed search time: 0 s
    searching for split with min-nodes 1835218, learned 0 good partial solutions
    Best solution until now: 2 tile(s). The smallest node count is 2042110 (81 %), the worst aspect ratio is near 2.42, elapsed search time: 0 s
    searching for split with min-nodes 2325000, learned 0 good partial solutions
    searching for split with min-nodes 2183555, learned 0 good partial solutions
    searching for split with min-nodes 2112832, learned 0 good partial solutions
    searching for split with min-nodes 2077471, learned 0 good partial solutions
    searching for split with min-nodes 2059790, learned 0 good partial solutions
    searching for split with min-nodes 2050950, learned 0 good partial solutions
    searching for split with min-nodes 2046530, learned 0 good partial solutions
    searching for split with min-nodes 2044320, learned 0 good partial solutions
    searching for split with min-nodes 2042111, learned 0 good partial solutions
    Solution is nice. Can’t find a better solution with search-limit 200000: 2 tile(s). The smallest node count is 2042110 (81 %), the worst aspect ratio is near 2.42
    Final solution: 2 tile(s). The smallest node count is 2042110 (81 %), the worst aspect ratio is near 2.42
    This seems to be nice.
    Area 90013001 covers (50.1416015625,9.580078125) to (50.712890625,11.7333984375) and contains 2042110 nodes (81 %)
    Area 90013002 covers (49.2626953125,9.580078125) to (50.1416015625,11.7333984375) and contains 2042514 nodes (81 %)
    Creating the initial areas took 47 ms
    2 areas:
    Area 90013001: 2336768,446464 to 2363392,546816 covers (0x23a800,0x6d000) to (0x241000,0x85800) MyOsmTopo-test-karte-gross
    Area 90013002: 2295808,446464 to 2336768,546816 covers (0x230800,0x6d000) to (0x23a800,0x85800) MyOsmTopo-test-karte-gross
    Generating problem list for 2 distinct areas
    Processing 2 areas in a single pass
    Pseudo areas:
    Pseudo area -3 covers (50.712890625,-180.0) to (90.0,180.0)
    Pseudo area -4 covers (-90.0,-180.0) to (49.2626953125,180.0)
    Pseudo area -5 covers (49.2626953125,-180.0) to (50.712890625,9.580078125)
    Pseudo area -6 covers (49.2626953125,11.7333984375) to (50.712890625,180.0)
    cached 7 combinations of areas that form rectangles.
    AreaGridTree [512][512] for grid area (-90.17166137695312,-180.17166137695312) to (90.17166137695312,180.17166137695312) requires max. 3 checks for each node (0 sub grid(s))
    Starting problem-list-generator pass(es)

Starting problem-list-generator pass 1 of 1
way Map: uses SparseLong2IntMap
coord Map: uses SparseLong2IntMap
Processing C:\MyOsmTopo\Kartenprojekt_MyOsmTopo-test-karte-gross\Hoehendaten_MyOsmTopo-test-karte-gross.osm
Processing C:\MyOsmTopo\Kartenprojekt_MyOsmTopo-test-karte-gross\Hoehendaten_MyOsmTopo-test-karte-gross.osm
coord Map: 4.084.624 stored long/int pairs require ca. 2.2 bytes per pair. 63.823 chunks are used, the avg. number of values in one 64-chunk is 63.
coord Map details: ~9 MB, including 1 array(s) with 8 MB

way Map: 51.133 stored long/int pairs require ca. 164.68 bytes per pair. 799 chunks are used, the avg. number of values in one 64-chunk is 63.
way Map details: ~8 MB, including 1 array(s) with 8 MB

Number of stored area combis for nodes: 4.084.624
Number of stored area combis for ways: 51.133
Number of stored Integers for rels: 0
Number of stored combis in dictionary: 19
Number of detected problem ways: 199
Number of detected problem rels: 0
JVM Memory Info: Current 77MB (23MB used, 54MB free) Max 966MB

Problem-list-generator pass 1 took 55547 ms
Problem-list-generator pass(es) took 55781 ms
cached 1 combinations of areas that form rectangles.
AreaGridTree [512][512] for grid area (49.091033935546875,9.408416748046875) to (50.884552001953125,11.905059814453125) requires max. 2 checks for each node (0 sub grid(s))

Executing multi-tile analyses phase 2
Processing C:\MyOsmTopo\Kartenprojekt_MyOsmTopo-test-karte-gross\Hoehendaten_MyOsmTopo-test-karte-gross.osm
Stats for MultiTileProcessor pass 2
SparseBitSet problemRels contains now 0 Ids.
SparseBitSet neededWays contains now 199 Ids.
SparseBitSet mpWays contains now 0 Ids.
SparseBitSet neededNodes contains now 1.084.383 Ids.
Number of stored relations: 0
Number of stored tile combinations in multiTileDictionary: 3
Status: Finished collecting problem ways.
Found 199 of 0 needed ways.
Found 0 of 0 needed multipolygon ways.
Stats for MultiTileProcessor pass 2
SparseBitSet problemRels contains now 0 Ids.
SparseBitSet neededWays contains now 199 Ids.
SparseBitSet mpWays contains now 0 Ids.
SparseBitSet neededNodes contains now 1.084.383 Ids.
Number of stored relations: 0
Number of stored tile combinations in multiTileDictionary: 3
Status: Starting to collect coordinates for 1.084.383 needed nodes.
JVM Memory Info: Current 77MB (68MB used, 9MB free) Max 966MB
Multi-tile analyses phase 2 took 26500 ms

Executing multi-tile analyses phase 3
Processing C:\MyOsmTopo\Kartenprojekt_MyOsmTopo-test-karte-gross\Hoehendaten_MyOsmTopo-test-karte-gross.osm
Error: Node ids are not sorted. Use e.g. osmosis to sort the input data.
This is not supported with keep-complete=true or --problem-list
uk.me.parabola.splitter.SplitFailedException: Node ids are not sorted
at uk.me.parabola.splitter.MultiTileProcessor.storeCoord(MultiTileProcessor.java:501)
at uk.me.parabola.splitter.MultiTileProcessor.processNode(MultiTileProcessor.java:127)
at uk.me.parabola.splitter.AbstractMapProcessor.consume(AbstractMapProcessor.java:62)
at uk.me.parabola.splitter.OSMFileHandler.execute(OSMFileHandler.java:159)
at uk.me.parabola.splitter.ProblemLists.calcMultiTileElements(ProblemLists.java:255)
at uk.me.parabola.splitter.Main.useProblemLists(Main.java:502)
at uk.me.parabola.splitter.Main.start(Main.java:127)
at uk.me.parabola.splitter.Main.main(Main.java:81)
Zum Starten -
Drücken Sie eine beliebige Taste . . .

gruss

Was kommt mit den vorgeschlagenen Optionen raus? Je nachdem, was Du mit den Daten später machst, sind die echt WICHTIG.
Wenn es dennoch nicht funzt, dann kannst Du es mal mit der splitter zusätzlichen option --keep-complete=false versuchen, dann stört sich splitter nicht dran, das die Daten nicht sortiert sind.

–keep-complete=false , ich denk das könnte es gewesen sein !!!

Die .pbf Dateien wurden mit dem splitter erzeugt
Danach hab ich mkgmap laufen lassen und aus den .pbf die .img erstellt .

Ergebnis :

Karte mit Höhenlinien und 3D wurde erstellt , ich würde euch gerne das Ergebnis zeigen aber Bilder kann man ja nicht hier hochladen .

Ich werde das jetzt noch bei einigen Tests ausprobieren und dann berichten !

was hat das mit den Sortierten oder nicht sortierten Ausgangsdaten .osm auf sich ?

aber eine Frage hab ich noch , die beiden Problem die ich hatte sollten doch andere User auch haben oder gehabt haben ?

Danke nochmal !!!

gruss

Wenn kepp-complete=true ist, ermittelt das Programm, welche Wege und Relationen die jeweiligen Kacheln betreffen, und sorgt dann dafür, dass die Daten komplett sind. Dafür ist aber die Sortierung der Daten notwendig, da splitter bei Bedarf auch ein planet.osm.pbf verarbeiten kann. Für Höhenlinien ist das eher unwichtig. Die meisten OSM Dateien sind von Haus aus sortiert (zuerst Nodes, dann Ways, dann Relationen, jeweils nach id aufsteigend sortiert)

Bestimmt. Es kursieren halt im Netz alle möglichen mehr oder weniger alten Beschreibungen und Beispiele, und niemand macht sich die Mühe, das aktuell zu halten, von löblichen Ausnahmen wie Bernhard Hillers Beiträgen zum wiki von srtm2osm mal abgesehen.
Falls Englisch kein Problem ist, solltest Du mal das Garmin Forum anschauen sowie die mkgmal Liste.
https://forum.openstreetmap.org/viewforum.php?id=26
http://gis.19327.n8.nabble.com/Mkgmap-Development-f5324443.html

Vorerst mal eine Zusammenfassung:

Das erstellen einer Karte im Format .img mit größeren Flächen und großen Höhendaten scheint zu funktionieren !

Das Problem mit den großen Kartenbereich wurde durch die neuere osmconvert64-0.8.8p.exe gelöst. (with large file support)
Und das Splitten der großen Höhendaten wurde durch den Zusatz im Befehl des splitters --keep-complete=false gelöst.

allen die dabei geholfen haben besten Dank !!!

gruss

Vielleicht können die lesen und verstehen ein paar Worte Englisch:

so schaut die Karte aus , ist für Radfahrer speziell !

nochmal danke an alle die geholfen haben !!!

gruss

Übrigens schreibt srtm2osm die Daten auch in der von splitter gewünschten Reihenfolge, wenn man die Option -incrementid mitgibt.
Es bleibt aber dabei, das für diese Daten die keep-complete Option sinnlos ist. Die Option overlap=8000 kannst Du wohl auch weglassen, der
default 2000 dürfte locker reichen.