Im Composer musst du nun grĂŒndlich AufrĂ€umen. Alle Regeln weg auĂer denen, die du fĂŒr die Symbole etc. benötigst. AnschlieĂend erstellst du dir eine Transparente png-Grafik mit 32*1px udn erzeugst daraus ein Weg-Kartenobjekt und damit eine Renderregel fĂŒr foo=bar.
Ich hoffe mal, dass der Composer die relations-Datei nicht löscht. Allerdings wird der Composer immer noch alle Daten verarbeiten, in der Karte tauchen sie dann aber nicht emhr auf.
@Nop: Wie bekommst du denn die Symbole auf die Wege? FĂŒgst du da Nodes fĂŒr ein?
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.
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.
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
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.
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.
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.
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.
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:
Eingangsdaten von Composer verarbeiten lassen
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.
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.
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
Edit:
@Nop: WÀre es evtl. sinnvoll, wenn du die API generell im Composer sperrst und nur XAPI und Extrakte als Input zulÀsst?
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.
