Neue Version 0.85 von Map Composer

Ja, das hatte ich dann irgendwann per trial und error auch schon herausgefunden.

Hm, das war bei mir nicht der Fall. Ist aber auch nicht das ,was ich erreichen möchte.
Ich möchte ja die Namen der Wege( und NICHT die Langbezeichnung der Route) + die Textmarkierung s.o.

Das war mir aufgefallen, ist mir in dem Fall aber egal.
Allerdings kann man die auch wiederbekommen, wenn man zu den Routen Einträge vom Typ “route_text” erzeugt. Wenn diese auf einen Labeltyp (0x2800)verweisen erhält das Symbolobjekt ein Label!!!. Es wird dann kein Extraobjekt erzeugt.

Sie wird nicht gelöscht allerdings anscheinend auch anderweitig völlig ignoriert.
So wie ich das im Moment sehe ist das wesentliche der Verarbeitung mit der Aufbereitung der Input-Daten erledigt.
Hiernach ist z.B. die Textmarkierung ins Namensfeld des Weges(nicht Route) übernommen.
Die Styles werden dann nur noch für die Erstellung der Garmin-Karte benötigt.

Im Moment sehe ich nur folgenden Weg:

  • Input-Datei vorbereiten durch externe Hinzufügung eines Tags zu jedem Weg, der Bestandteil einer Route ist
    So lassen sich diese Wege dann einfach identifizieren und das Erstellen der Routenmarkierung kann entfallen.
    Es übersteigt meine Fähigkeiten mit akzeptablen Aufwand eine Skript zu schreiben,
    welches dieses bewerkstelligt.
    Nachteil ist auch, das die Inputdatei weiter aufgebläht würde.
  • Diese Datei dann mit Composer verarbeiten

Nochmals Danke für eure Ideen
Gert

Sagte ich ja, dass der Composer wieterhin alle Daten verarbeitet, aber mkgmap schriebt nurnoch die Wege in die img-Dateien, die auch einer Relation angehören.

Aber nur wenn mkgmap dies erkennen kann.
in der …data.osm sind Weg+Route schon aufbereitet und das relations-file wird offensichtlich nicht beachtet.
Also kommt das Tag nicht zum Weg (Ich sehe da aktuell auch keinen einfachen Weg noch ein Tag reinzubekommen.) ergo kann mkgmap nicht erkennen welcher Weg nun rauszusuchen ist.
Wenn das wenigstens ginge könnte die weitere Verarbeitung ja manuel mit mkgmap erfolgen.

Was geht ist die …data.osm +…routes.osm wieder zusammenzuschreiben und dann manuell mit mkgmap weitermachen. Dort kann man dann via relations ein tag zufügen und nur diese rausschreiben.
Im Moment habe ich noch keine Vorstellung wie ich das Zusammenfügen bei größeren Datenmengen am besten mache.

Gruss
Gert

Stimmt, daran hab ich nicht gedacht :frowning:

Dann braucht man wohl doch einen Filter, der Relationen analysiert, den Memberwegen ein Tagg spendiert und dann diese Wege, die betreffenden Nodes und die Relationen in eine osm-Datei schreibt. Mit der kann man dann den Composer füttern.

Composer macht die Analyse ja doch schon, es müsste “lediglich” bei Bedarf ein Tag an die Memberwege anfügen und eine dies entsprechend auswertende Regel in die styles übernommen werden

Gruss Gert

Mal ganz anders herum gedacht -
(Die folgende Idee funktioniert allerdings vermutlich nur mit überschaubaren Regionen.)
In JOSM gibt es mächtige Filterfunktionen.
Damit ist es möglich, ein Extrakt von allen Wegen zu erstellen, die Mitglied einer Routenrelation sind.
Hat man alle Member einer Routenrelation isoliert, kann man diesen Wegen in einem Rutsch ein beliebiges zusätzliches Tag verpassen.
Sammelt man die Extrakte mehrerer Downloads in einer lokalen Datei auf dem PC, erhält man eine Datei, die sich mit Composer verarbeiten läßt.

Gruß
tippeltappel

Damals hatte sich Nop gegen jegliche Vererbungsmöglichkeit von Realtionen auf andere Objekte gesperrt, weil es zu Problemen führen kann wenn man nicht genau weiß, was man tut…

@Tippeltappel…das sollte man tunlichst vermeiden. Das belastet die API nur unnötig.

Deinen Einwand verstehe ich nicht. Wenn man eine Region mit JOSM bearbeitet, lädt man sie doch ohnehin herunter.
Was liegt da näher, als die Daten auf dem PC zu speichern und daraus dann die Routen-Wege zu extrahieren. Das ist für die API doch dann keine zusätzliche Belastung.

Ist alles eine Frage der größe des Gebiets. Bei einer Stadt mit sicherheit kein Problem. Hier ging es aber eher um eine ganze Wandergegend oder noch mehr. Das sollte man der API nicht antun. Vorallem könnte es auch jOSM sprengen.

Deshalb schrieb ich “mit überschaubaren Regionen”

Ich habe JOSM auf einem Offline-Rechner installiert und dort schon Verschiedenes mit dem Programm ausprobiert, ohne auf irgendeine Weise mit OSM-Servern Kontakt aufzunehmen.
Unter anderm auch Daten extrahiert und in neuen Dateien abgelegt. Das funktionierte ganz gut.
Da sich Wanderrouten nicht “alle Nas lang” ändern, stelle ich mir vor, daß man sich im Laufe der Zeit systematisch mit der Erfassung der Wanderrouten befaßt und dabei dann die Sammlung anlegt. Wie das im Detail funktioniert und ob und wenn ja welche Schwierigkeiten auftreten, müßte man halt testen.

Gruß
tippeltappel

Ich muss das noch mal klarer machen.
in der …data.osm befinden sich die Wege + routemarker, aber keine Routen mehr( route=hiking etc. fehlt)
Das ist dann auch der Grund warum das relations-file nichts bewirkt. Nicht weil composer es ignoriert, sondern mkgmap findet keine Entsprechung im …garmin.osm( welches wohl widerum aus …data.osm generiert wird)
Sobald data + routes wieder vereint sind funktioniert es auch direkt über Composer.

Die Krux scheint mir somit, möglichst einfach diese Wiedervereinigung zu bewerkstelligen.

Die Idee es mit der eh schon vorhandenen lokalen Datei in JOSM zu machen ist interessant.
Allerdings sind mir da mit 1GB RAM enge Grenzen gesetzt. Und wenn ich mir die Ladezeiten etc. bei schon kleineren Dateien <100Mb anschaue, bin ich da nicht so optimistisch. Mal sehen vielleicht schaue ich mir das aber doch noch mal an.

Gruss Gert

Mußt halt eine kleine Download-Datei nehmen.
Der Extrakt ergibt eine deutlich kleinere Datei. Denn da schmeißt Du ja jede Menge raus. Somit sollten sich mehrere Extrakte kombinieren lassen.
Wenn aus welchen Gründen auch immer mehrere OSM-Dateien mit den Extrakten erstellt werden müssen, kannst Du versuchen, sie auf folgende Weise mit Hilfe des Composers zu einer Karte zu vereinen:
Für jede Extrakt-Datei legst Du in Composer eine Region an und bindest die “Extrakt-OSM-Datei” als “lokale OSM-Datei” ein.
Dann legst Du einen Job an, der alle so definierten Regionen verbindet.

Gruß
tippeltappel

Sorry, da muss ich mich korrigieren.
Es ist zwar so das dann das Symbolobjekt eine Label hat, der Wert dann aber im Namen des Weges fehlt.
Allerdings ist mir dann aufgefallen das manchmal das Symbol mit Label(und der Weg ohne diesen Namensteil) und manchmal auch andersrum(Symbol ohne Wegmit) generiert wird. Evtl. hängt es ja mit den Einstellungen der Längen bei Routen zusammen
Nach 3 Tagen der Probiererei gebe ich es jetzt erstmal auf verstehen zu wollen, wie Composer da gestrickt ist.

Ich erstelle mein Overlay jetzt wie folgt:

  1. Eingangsdaten von Composer verarbeiten lassen
  2. Batchdatei starten
    2.a. …data + …routes.osm aus 1. via Perlskript zu einer Datei zusammenfassen
    2.b Diese Data mit mkgmap und eigenen styles weiterverarbeiten( s.o tag schreiben wenn route=hiking etc.
    und nur dieses Tag zusammen mit den Symbolen rausschreiben

Als Ergebnis erhalte ich ein img das nur eine Linienmarkierung für die Route(benannt Wegenamen +
dem Textmarkierungsfeld aus der Route) + die Symbole enthält.

Nochmals Dank für eure Unterstützung

Gert

Ich habe heute meine Region als Download vom API-Server aktualisiert. Dabei hat das »logbuch=errorLog.txt« diesen Fehler ausgeschrieben.
Ich verstehe den so, dass beim Download eine Datei oder ein Datenteil nicht gefunden wurde …

Kann/würde mir bitte jemand erklären, was das genau bedeutet und was ich ggf. falsch gemacht habe? Danke!

Torsten,
der sich gerade in die unendlichen Weiten der MapComposers einarbeitet. :wink:

Unabhängig vom Composer-Fehelr hast du den KArdinalsfehler begangen und von der API geladen. Die API ist aber egtl. nur fürs Mapping da. Für den Rest sollte man die XAPI nutzen oder noch besser fertige Extrakte.

Den Composer-Fehler würde ich ähnlich interpretieren. Wahrscheinlich ist der Bereich für die API flächenmäßig zu groß oder hat zuviele Elemente. Lösung siehe oben :wink:

Edit:

@Nop: Wäre es evtl. sinnvoll, wenn du die API generell im Composer sperrst und nur XAPI und Extrakte als Input zulässt?

Hmmm …

Mein Probefenster ist 5 Längengrade x 3 Breitengrade groß. Soll das zu groß sein?

In meiner Version steht zu Auswahl:

  • Download vom API server (Originaleinstellung)
  • Ausschnitt aus Planet Datei (keine Ahnung was das ist)
  • Lokale OSM Datei komplett (die wollte ich aktualisieren)

Womit soll ich aktualisieren?

Das einfachste wäre, wenn du dir ein entsprechendes Extrakt herunterlädst und mit diesem dann deine bisherige Datei überschreibst.

Beim zweiten kannst du eine BoundingBox angeben und er schneidet die angegebene lokale OSM Datei auf diesen Bereich zurecht. Bzw. du kannst auch in den Job-Einstellungen ein Polygon-File angeben, welches der Composer dann ausschneidet.

Aktualisieren bedeutet ab in jedem Fall herunterladen aller Daten.

Ja bitte auf die XAPI ändern! Wenn das standardmäßig an ist und man die ganzen DAUs, die ja in dem Fall nicht mal was dafür können, auf die API losläßt, dann ist es ja kein Wunder das die API lahm ist und die Admins mit sperren der User nicht hinterherkommen. Bitte nur Extrakte/Planet, XAPI und fertige *.osm -Datein zum laden anbieten, also keine API-Downloads oder Aktualisierungen.

Ja, das is definitiv zu groß, die API ist auf ein 0,5 Grad und 50000 Nodes begrenzt, die ist überhaupt nicht dafür geeignet und gedacht. Am besten nimmt man für Deutschland wenn man ein etwas größeres Stück braucht die Bundesländer oder Deutschlandextrakt von der Geofabrik. Sonst die XAPI, die jetzt noch lahm ist, weil sie in einer Exotenprogrammiersprache geschrieben wurde, die aber laut Liste wohl schon auf Java protiert wird und in einiger zeit dann hoffentlich auch schneller sein wird.

Da wuerde ich mir mal nicht so viel Hoffnung machen. XAPI ist zwar in einer exotensprache geschrieben und wird zur Zeit auf Java portiert, ob es desshalb aber significant schneller wird, wage ich aber mal zu bezweifeln. Der grosse Vorteil des rewrites ist das er besser zu maintainen ist und man somit theoretisch viele neue XAPI server installieren koennte. Ob allerdings tatsaechlich massiv mehr Hardware der XAPI entgegen geschmissen wird muss man sehen, glaube ich aber beinahe nicht.

Fuer das (komplette) Herunterladen von groesseren Gegenden ist also auch die XAPI nicht geeignet. Es sollte imho also auch die XAPI nicht fuer soetwas empfohlen werden, wenn es sich nicht nur um ein paar Strassen oder ein Dorf handelt. (Allenfalls trapi ist etwas besser dafuer geeignet, aber selbst die wuerde mit vielen requests bald ueberfordert sein http://api1.osm.absolight.net/api/0.6/map?bbox=))

Planet extracts sind also eigentlich fuer Endanwender nahezu alternativlos (um das Unwort des Jahres zu verwenden). Zum Glueck bietet die Geofabrik eine gute Auswahl and sehr aktuellen planet extracts sodas das eigentlich kein Problem sein sollte.

… eigentlich … Das ist genau das richtige Wort, denn es gibt durchaus Situationen, in denen man mit den aktuellen Downloadangeboten nicht wirklich gut weiter kommt. Stichwort “Grenzgebiete” Davon wird es immer mehr geben. Große Bundesländer werden längst in kleinere Einheiten aufgeteilt angeboten. Die Gründe dafür kann sich jeder selbst denken …

Gruß
tippeltappel