Frage zu OSM Composer

Hallo Jürgen,

ich würde dir raten, mal mit etwas kleineren Karten zu beginnen.

Mit dem Composer werden 2 Beispielgebiete mitinstalliert. Kannst du diese beiden erfolgreich erzeugen? Das sollte mit der Defaulteinstellung eigentlich gehen.
Dann habe ich angefangen, einen Wien-Plan zu erstellen (nur das Stadtgebiet selbst), dann Wien-Umgebung und zuletzt Ost-Österreich.
So habe ich mich langsam zu immer größeren Gebieten vorgetastet.
Als nächstes möchte ich den Composer mit MySQL koppeln, um auch ganz Österreich als Karte zu erzeugen.
Ich hoffe, diese Tipps helfen dir vorerst mal weiter.

Walter

Hi!

Erst mal ist es ein gutes Zeichen, daß die Beispielkarten funktioniert haben. :-)

Insterman wrote:

Wäre schön, wenn mir jemand den ein oder anderen Tipp gegen könnte.
1. Bei Einstellung Datenquelle = "Ausschnitt aus Planet Datei" kommt im Log stets "osmosis call failed". Dann gehts nicht weiter.
Was mache ich da falsch?

Führe den Versuch noch einmal durch und schau danach in die Datei commands.log. Da siehst Du den Aufruf und evtl. genauere Fehlermeldungen. Wenn Dir nix auffällt, poste sie mal.

Insterman wrote:

2. Bei „Download vom API server“ kommt im Log-Ausschnitt z.B.:
"Downloading http://api.openstreetmap.org/api/0.6/ma … 1,7.2,60.0 java.nio.BufferUnderflowException
Newer input file detected"

Das klingt nach einem Problem, das in der nächsten Version gefixt sein wird. Wenn beim Einspielen der Daten bereits ein Problem aufgetreten ist, ist es wahrscheinlich daß die Karte leer ist oder Löcher zeigt. Welchen Bereich versuchst Du denn insgesamt herunterzuladen?

Insterman wrote:

4. Die gewünschte Karte am Stück bekommen ich gar nicht durch (trotz mehrerer Stunden Laufzeit).
Wenn ich mehrere Teilkarten erstelle, mit zusammenpassenden Randkoordinaten, kann ich die dann wieder irgendwie zu Einer zusammenführen?

Grundsätzlich würde ich Dir auch raten, mit kleinen Karten anzufangen und sie allmählich zu vergrößern. Für die Datenmengen, mit denen Du anscheinend arbeiten willst, sind Planetfiles deutlich günstiger, der API-Download dauert dafür ewig. Man kann Karten auch aus Einzelregionen zusammensetzen, dann entstehen aber momentan Artefakte an den Schnittkanten, weil Osmosis einen destruktiven Schneidealgorithmus verwendet.

bye
Nop

Hallo,
also ich hab jetzt nichts weiter zu „Insterman“ seinen Problem zu sagen aber ist es auch möglich eine Karte aus mehreren OSM Fils zu erzeugen.
Also bis jetzt mache ich das auch immer über API (14.0-15.3//50.6-51.3) aber das dauert halt immer, aber ich habe auch die drei OSM Daten von GEOFABRIK zur Verfügung, Sachsen; CS und PL.
Kann man den Composer so einstellen das er aus diesen drei Dateien diesen Bereich generiert, hab das schon mal versucht aber bin gescheitert, weil man unter Region ja immer nur eine Lokale Datei auswählen kann. Oder hab ich was übersehen.
Danke und Gruß Jörg

Hallo Jörg,

imComposer kannst du nur 2 osm-Dateien zusammenbringen, wobei ich mir nicht sicher bin, ob diese gemerged werden oder nicht. Ich hab den verdacht, dass sie einfach nur hintereinander in den Splitter geschickt werden und die zweite Datei nicht zurechtgeschnitten wird. (@Nop: Könntest du mich und auch die anderen darüber aufklären?)

Ansonsten kannst du natürlich die Planetfiles mit osmosis zu mergen. Ist auf der wiki-Seite von osmosis erklärt, wie man es machen muss. Bei Problemen findest du hier auch Hilfe...Ich hab leider meine Aufrufe erst wieder am WE greifbar.

@Nop: DAzu gleich noch eine Frage: Wenn du auf Osmosis 0.33 umsteigst, steigst du doch auch auf API0.6 um, oder?

AlterSachse wrote:

Kann man den Composer so einstellen das er aus diesen drei Dateien diesen Bereich generiert, hab das schon mal versucht aber bin gescheitert, weil man unter Region ja immer nur eine Lokale Datei auswählen kann. Oder hab ich was übersehen.

Nein. Du mußt den Bereich dann aus dem Europa-File ausschneiden.

Es ist nicht möglich, mehrere Planetfiles wieder zusammenzusetzen, da sie bereits beim Erzeugen durch Osmosis entlang der Schnittkanten beschädigt wurden. Man hat dann immer erkennbare Artefakte entlang der Schnittlinien.

bye
Nop

aighes wrote:

imComposer kannst du nur 2 osm-Dateien zusammenbringen, wobei ich mir nicht sicher bin, ob diese gemerged werden oder nicht. Ich hab den verdacht, dass sie einfach nur hintereinander in den Splitter geschickt werden und die zweite Datei nicht zurechtgeschnitten wird.

Die Daten aus der 2. Datei werden genauso behandelt wie die übrigen auch, also auch geschnitten. Das ist aber für Overlays wie Seepolygone gedacht, nicht für ganze Planetfiles.

aighes wrote:

@Nop: DAzu gleich noch eine Frage: Wenn du auf Osmosis 0.33 umsteigst, steigst du doch auch auf API0.6 um, oder?

Verstehe die Frage nicht. Die Umstellung auf API0.6 war Mitte 2009.

bye
Nop

Meines Wissens spuckt Osmosis 0.29, welches der Composer bisher verwendet hat die osm-Datei als 0.5 aus. Zumindest zeigte mir jOSM und auch neuere Osmosis-Versionen an, dass es sich um 0.5 handelte und nicht um 0.6. Wenn du jetzt osmosis 0.33 nutzt, könnte es Probleme geben mit OSM-Dateien, die mit osmosis 0.29 behandelt wurden. Sprich man müsste alle Daten einmal neu erstellen lassen. Daher die Nachfrage, bzw. der Hinweis.

Es gibt doch auch die Möglichkeit, von der API Änderungsfiles (je Tag oder auch je Stunde) herunterzuladen.
Wäre es damit möglich, dass ich einmal das gesamte Europa Planetfile über Nacht lade und dann für die letzten Tage nur die Änderungen?
Wenn ja, wie kann ich diese Files dann zusammen an den Composer schicken?

Der Composer ist standardmäßig auf den Download von http://api.openstreetmap.org/ eingestellt.
Ich habe das bei mir auf http://www.informationfreeway.org/ geändert und komme damit besser klar. (keine Abbrüche beim Download mehr)

Walter

aighes wrote:

Meines Wissens spuckt Osmosis 0.29, welches der Composer bisher verwendet hat die osm-Datei als 0.5 aus. Zumindest zeigte mir jOSM und auch neuere Osmosis-Versionen an, dass es sich um 0.5 handelte und nicht um 0.6. Wenn du jetzt osmosis 0.33 nutzt, könnte es Probleme geben mit OSM-Dateien, die mit osmosis 0.29 behandelt wurden. Sprich man müsste alle Daten einmal neu erstellen lassen. Daher die Nachfrage, bzw. der Hinweis.

Ach so. Diese Versionsangabe ist irrelevant. Die Daten gehen nie wieder über die API und Composer, mkgmap, Kosmos usw. interessieren sich nicht dafür. Aber da steht in Zukunft 0.6.

bye
Nop

Walter Schlögl wrote:

Es gibt doch auch die Möglichkeit, von der API Änderungsfiles (je Tag oder auch je Stunde) herunterzuladen.
Wäre es damit möglich, dass ich einmal das gesamte Europa Planetfile über Nacht lade und dann für die letzten Tage nur die Änderungen?
Wenn ja, wie kann ich diese Files dann zusammen an den Composer schicken?

Du mußt ein Programm finden, daß Dir die Diffs in Deinen lokalen Datenbestand wieder integriert und die Datei ganz normal an Composer übergibt, wie einen Download. Keine Ahnung ob es so ein Programm gibt.

bye
Nop

Hallo und Guten Morgen an Euch alle,
Danke für die Infos.
Also war ich doch nicht ganz so auf den falschen Dampfer, muss ich halt die Karte weiter über API erstellen.
Die EU Karte ist ein wenig zu groß und dauert somit länger als der API Download.
Werde mal die URL von "Walter" probieren.

• • Nop mach weiter so, ich warte schon gespannt auf die 0.82 damit die Routen wieder im API Download auftauchen, muss im Moment ohne Wegmarkierung leben ;-)
    

Das Progi verdient 5 Sterne **

Gruß Jörg

Hallo Nop,

ich denke, Osmosis kann in Verbindung mit einer Datenbank Diff-Files in einen Datenbestand einarbeiten.
Allerdings ist mir das derzeit noch einige Nummern zu groß.

Hallo Jörg,

informationfreeway ist eine alternative API-Schnittstelle mit dem Nachteil, dass die Daten einige Minuten alt sind und dass keine Uploads möglich sind (hier nicht benötigt).
Der Vorteil ist, dass ein größeres Gebiet am Stück geladen werden kann (wird beim Composer auch nicht benötigt) und nach meiner Beobachtung ein stabileres Antwortverhalten.

Walter

Walter Schlögl wrote:

informationfreeway ist eine alternative API-Schnittstelle mit dem Nachteil, dass die Daten einige Minuten alt sind und dass keine Uploads möglich sind (hier nicht benötigt).
Der Vorteil ist, dass ein größeres Gebiet am Stück geladen werden kann (wird beim Composer auch nicht benötigt) und nach meiner Beobachtung ein stabileres Antwortverhalten.

Ehrlich gesagt klingt das so, also ob ich besser diese API als Voreinstellung für Composer nehmen sollte. Schnellere Antwortzeiten und größere Gebiete sollten die Arbeit deutlich komfortabler machen. Wie sieht es mit der Verfügbarkeit aus?

bye
Nop

Ich muss nochmal auf meine Ursprungsfragen zurückkommen.
Erst mal Danke an Alle für Eure Hinweise.

An NOP:

Zu 1: Ich hab's nochmal probiert. In der Commands.log steht
25.02.2010 19:24:05 com.bretth.osmosis.core.Osmosis main
SCHWERWIEGEND: Execution aborted.
com.bretth.osmosis.core.OsmosisRuntimeException: Argument 2 doesn't contain a value after the '=' (ie. name=value).
at com.bretth.osmosis.core.cli.CommandLineParser.parseTask(CommandLineParser.java:295)
at com.bretth.osmosis.core.cli.CommandLineParser.parse(CommandLineParser.java:89)
at com.bretth.osmosis.core.Osmosis.main(Osmosis.java:38)

Was muss ich ändern?

Zu 4:
Generell versuche ich wohl, zu große Karten zu erstellen.
Im Endeffekt hätte ich gerne:
Länge : 4.45 – 13.0
Breite : 58.0 – 64.0

Wie geht denn das Zusammensetzen der Einzelkarten?

Gruß und Danke,
Jürgen

kleiner Nachtrag.
Vielleicht sollte ich die gesammte Commands.log anfügen:

reg delete "HKEY_LOCAL_MACHINE\SOFTWARE\Garmin\MapSource\Families\OSMC NOK_2" /f

rem Cutting data with osmosis

java -Xmx1100M -jar C:\Tools\Garmin\OSM_Composer\Tools\osmosis.jar --read-xml file= enableDateParsing=no --tee outputCount=1 --bounding-box bottom=58.8 left=5.0 top=60.0 right=7.2 --write-xml file=C:\Tools\Garmin\OSM_Composer\input\NOK_2_input.osm

25.02.2010 19:24:05 com.bretth.osmosis.core.Osmosis main
SCHWERWIEGEND: Execution aborted.
com.bretth.osmosis.core.OsmosisRuntimeException: Argument 2 doesn't contain a value after the '=' (ie. name=value).
at com.bretth.osmosis.core.cli.CommandLineParser.parseTask(CommandLineParser.java:295)
at com.bretth.osmosis.core.cli.CommandLineParser.parse(CommandLineParser.java:89)
at com.bretth.osmosis.core.Osmosis.main(Osmosis.java:38)

Für so ein großes Gebiet empfehle ich dir die europe.osm von bspw. http://download.geofabrik.de/osm/

Aber auch von mir der Rat: Nimm erstmal kleine Ausschnitte. Für ganz Skandinavien benötigt der Composer gut 8gb RAM.

Insterman wrote:

java -Xmx1100M -jar C:\Tools\Garmin\OSM_Composer\Tools\osmosis.jar --read-xml file= enableDateParsing=no --tee outputCount=1 --bounding-box bottom=58.8 left=5.0 top=60.0 right=7.2 --write-xml file=C:\Tools\Garmin\OSM_Composer\input\NOK_2_input.osm

Ich würde mal vermuten, Du hast in der Region angeklickt "Ausschnitt aus Planetfile", aber keinen Dateinamen im Textfeld eingetragen.

bye
Nop

HAllo Nop,
da sollte es aber dann eine Überprüfung geben, ob die Datei existiert. Entweder direkt beim Speichern der Region oder vor dem Aufruf und dann eine entsprechende Meldung. Gleiches auch für die beigefügte osm-Datei.

aighes wrote:

da sollte es aber dann eine Überprüfung geben, ob die Datei existiert. Entweder direkt beim Speichern der Region oder vor dem Aufruf und dann eine entsprechende Meldung. Gleiches auch für die beigefügte osm-Datei.

Naja, kann ich einbauen. Aber es gibt schon Fehler, die so grundsätzlich sind, daß sie nicht flächendeckend abgefangen werden. Z.B. gibt es auch keine Prüfung, ob die Koordinaten für den Kartenausschnitt überhaupt existieren. :-)

bye
Nop

Wie ob die existieren? Ich ging davon aus, dass du den Wertebereich -180 bis +180 schon überprüfst. Gut, wenn es dann in der OSM-Datei dazu keine Werte gibt, dann ist man als ersteller selber Schuld...Sowas sollte dann aber auch im Übersichtsfenster der Regionen auffallen. Ist mir auch schonmal passiert...war sogar schon kurz davor den Monitor zu prügeln ;-) dann sah ich, dass ioch Länge und Breite vertauscht habe :-D

Aber mMn gehört es dazu beim Einlesen (oder einlesen lassen) einer Datei dazu vorher zu überprüfen, ob diese auch wirklich vorhanden ist.

Hallo, also ich hab jetzt die andere URL probiert aber da geht nichts.
Nach 24 min steht es immer noch bei Sektion 1/98 und das Netzwerk bringt was von 4 kb/s.
Log:

http://www.informationfreeway.org/api/0.6/map?bbox=14.999999999999996,50.7,15.099999999999996,50.800000000000004
Downloading
http://www.informationfreeway.org/api/0.6/map?bbox=15.099999999999996,50.7,15.199999999999996,50.800000000000004
Downloading

Mit der http://api.openstreetmap.org URL dauert das ganze nur 5min und die 98 Segmente sind geladen und das bei 1000 kb/s Durchschnitt
Also ich bleibe bei http://api.openstreetmap.org gut abends ist das ganze etwas schwächer als wie jetzt der Test früh um 9°°. Aber mit der anderen Adresse hatte es mir in den 24 min gerade mal 3MB runtergeladen von den 110 MB die die Datei am Ende groß ist.
Oder hab ich was falsch gemacht?
Gruß Jörg

@ AlterSachse
Das hängt möglicherweise damit zusammen, wie hoch gerade der Zugriff auf dem Freeway-Server ist.

@ Insterman
"Wie geht denn das Zusammensetzen der Einzelkarten?"

Mit Composer 0.77 funktioniert es z.B. so:

1. Lege Regionen in überschaubarer Größe an (z.B. 1 Grad hoch und breit)

2. Lege für jede Region einen Job an, der eine Einzelkarte dieser Region erstellt.
- achte darauf, daß die Kartenkacheln (nicht mit der Segmentgröße des Downloads verwechseln!)
für alle Einzelkarten mit derselben Größe angegeben werden;
> verwende als Daten-Quelle keinesfalls ein Planetfile
> Rendere jede Region mit einer eigenen ID
> kontrolliere das Ergebnis; vor allem prüfe, ob beim Download Löcher entstanden sind;
> ist die Einzelkarte ok, weiter mit 3.

3. Sichere die Input-Datei jeder Einzelkarte händisch in einem Input-Ordner, auf den Composer keinen Zugriff hat

4. Sichere von jeder Einzelkarte folgende Dateien händisch in einem Data-Ordner, auf den Composer keinen Zugriff hat:
- nn_contour.osm
- nn_data.osm
- nn_poly.osm
- nn_routes.osm
nn=von Dir gewählter Name der Karte
Je nach Größe der Region und Größe der Kartenkachel können auch mehrere contour.osm-Dateien erzeugt werden.
Die müssen dann alle gesichert werden.
- Ist die Sammlung komplett, lege noch eine Sicherheitskopie dieses Verzeichnisses an.

5. Überprüfe und bearbeite die Renderregeln
- aktiviere die Routen in der Routenliste
- erstelle Ersetzungsregeln
- etc.

6. Lege einen Job an, der alle Regionen bearbeitet, von denen bereits eine Einzelkarte erstellt wurde.
- Datendownload > deaktiviert
- Erstellung der Höhenlinien > deaktiviert
- Composer "immer"

7. Rufe im Composer "Einstellungen" auf und lege als Datenverzeichnis den Pfad fest, in dem Composer die gesammelten Data-Dateien findet (siehe Punkt 4)

8. Starte den Rechner neu, damit alle Kapazitäten des Rechners resettet sind.

9. Rufe den Job auf, der alle Regionen zu einer Gesamtkarte verbindet.
Wenn alle Arbeitsschritte korrekt verlaufen sind, sollte folgendes funktionieren:
- Composer erkennt die vorbereiteten Daten und berechnet daraus eine neue Karte.
- Dabei erstellt er für jede Region neue nn_garmin.osm.gz-Dateien. "nn" zeigt die enthaltenen Regionen an.
- Anschließend erstellt Composer nebst Protokolldateien einen *.img-Satz, *.tdb, *.txt, *.typ
- Die Kacheleinteilung der Einzelkarten wird (zumindest in Composer 0.77) in die Gesamtkarte übernommen.

Gruß
tippeltappel

@tippeltappel

Danke für die ausführliche Beschreibung. Damit werde ich mal experementieren.

Gruß, Jürgen

Insterman wrote:

@tippeltappel

Danke für die ausführliche Beschreibung. Damit werde ich mal experementieren.

Gruß, Jürgen

Gern geschehen.
Ich bin gespannt, wie es bei Dir klappt.

Die Sicherung der Input-Dateien hat folgenden Grund:
Beim Experimentieren kann man schon mal versehentlich einen Job anwählen, der unnötigerweise ein neues Download auslöst. Sobald der Job gestartet wird, ist die vorhandene Input-Datei "kaputt" und eine Berechnung der darauf basierenden Karte nicht mehr möglich. Da so ein Versehen viel Zeit kosten kann und obendrein nicht immer ein fehlerfreies Download gelingt, empfehle ich nach jedem gelungenen Datendownload die Inputsicherung. Damit ist der Flüchtigkeitsfehler rasch korrigiert.

Gruß
tippeltappel

@tippeltappel
Hallo, scheint nicht an der Serverlast zu liegen habe es gerade noch mal probiert, bleibt nach einer Minute wieder dort stehen und nach 20 min sind nur 2MB runter gekommen.
Anscheint mag der meine Region nicht :-(
Deine Anleitung finde ich gut und werde sie probieren.
Gruß und schönes WE Jörg

Hallo Nop,

ich habe mit der XAPI bessere Erfahrungen gemacht als mit der Original API, aber wie oben bereits beschrieben, trifft das wohl nicht auf alle Anwender zu.
In der Wiki-Anleitung habe ich die alternative API eingetragen, dann kann jeder selber experimentieren.
Erfahrungen habe ich eher wenige, da ich meistens das Planetfile vor dem Composer-Lauf bereits herunterlade.

Falls du wirklich im Composer von der Möglichkeit des Downloads größerer Flächen (bis 100 Quadrad-Grad) pro Aufruf Gebrauch machen möchtest,
ist ein Umschalter zwischen API und XAPI notwendig, da ja die Original API nur 0.25 Quadrad-Grad erlaubt.

http://wiki.openstreetmap.org/wiki/DE:Xapi

Walter

Meine Erfahrung mit API:
Downloads mit API funktionieren immer dann gut, wenn die Segmente der darin enthaltenen Datenmenge entsprechend eingestellt sind:
- Hohe Datendichte erfordert kleine Segmente (unter Umständen 0.02).
- Geringes Datenaufkommen erlaubt große Segmente (0.1).

Immer dann, wenn die Segmente für das Download auffallend viel Zeit benötigen, ist das Datenaufkommen in diesem Bereich sehr hoch. Solange die Segmentgröße händisch eingestellt werden muß, sollte man in so einem Fall nach dem Download sofort die Konfiguration ändern (Segmentgröße verkleinern) und für das nächste Download abspeichern. Durch den stetigen Datenzuwachs muß man ansonsten damit rechnen, daß dieser Bereich beim nächsten Download nicht mehr funktioniert (> java.io.IOException: Server returned HTTP response code: 500 for URL: http://api.openstreetmap.org/api/0.6/map?bbox=)

Keine Angst vor kleinen Segmenten und damit einhergehender hoher Stückzahl! - Da sie weniger Daten beinhalten, werden kleine Segmente in rascher Folge herunter geladen. Wenn die Einstellung stimmt, tickern bei mir durchschnittlich 3 Segmente in 2 Sekunden durch. Nur solche, die extrem voll gepackt sind, benötigen mehr Zeit. Ausfälle sind bei solcher Einstellung gering oder kommen gar nicht vor.

Wenn in einer Region an nur wenigen Stellen hohe Datendichte ein ansonsten gut funktionierendes Download mit relativ großen Segmenten stört, ist es von Vorteil diese Bereiche als separate Regionen zu definieren. Die Mühe wird mit deutlicher Zeitersparnis belohnt, weil man die Bereiche mit geringer Datendichte in großen Segmenten herunter laden kann.

So jedenfalls mußte man das Download noch bis Version 0.80 / 0.81 (?? - bitte in der History nachsehen!) organisieren.
Der neue Composer nimmt einem diese Arbeit ab.

Wenn der Composer (weiß jetzt grad nicht, ab welcher Version - bitte History nachlesen) keine Antwort vom Server bekommt, setzt er die Segmentgröße automatisch herunter. Bereiche mit geringer Datendichte werden in großen Segmenten (gemäß Voreinstellung) abgerufen. Die automatische Anpassung der Segmentgröße an die Datendichte erleichtert die Organisation des Downloads und beschleunigt es deutlich.

Noch arbeite ich mit der V 0.77 und stelle daher die Segmentgröße von Hand ein. Ich steige erst mit der Version 0.82 um.
Auf die Neuerungen bin ich sehr gespannt.

Gruß
tippeltappel

AlterSachse wrote:

@tippeltappel
Hallo, scheint nicht an der Serverlast zu liegen habe es gerade noch mal probiert, bleibt nach einer Minute wieder dort stehen und nach 20 min sind nur 2MB runter gekommen.
Anscheint mag der meine Region nicht :-(
Deine Anleitung finde ich gut und werde sie probieren.
Gruß und schönes WE Jörg

So etwas habe ich auch schon mit API erlebt. Irgendwann kam ich drauf, daß das lange Warten nichts nutzt. Hab einfach die Internetleitung gekappt (System > Lanverbindung > deaktivieren) und anschließend sofort wieder aktiviert und schon fluppte das Download.

Viel Erfolg! :-)

Gruß
tippeltappel