OSM Composer sucht Unterstützung

Hallo!

OSM Composer soll die Hürde für das Gestalten und Erstellen eigener (Garmin) Karten verringern. Die Zielgruppe sind normale Anwender ohne tiefen technischen Hintergrund, Kommandozeilenbegeisterung und viel, viel Zeit zum Rumprobieren. Das Mittel ist eine konsistente graphische Oberfläche, die sich um die ganzen fitzeligen Details kümmert. Bisher wurde OSM Composer hauptsächlich in Richtung auf mein eigenes Interesse Wanderkarte und mit dem Feedback aus der Community entwickelt. Jetzt wollte ich mal rumfragen, ob jemand Lust hätte, konkret mit daran zu arbeiten, Composer für weitere Anwendungsgebiete zu öffnen. Dabei gäbe es auch einige interessante Dinge, für die keine Programmierkenntnisse erforderlich sind, das wäre also kein Hindernis. Konkret dachte ich an Themen wie:

  • Alternative Kartenstile: Composer kommt standardmäßig konfiguriert für eine Topo-Wanderkarte. Vielleicht hätte jemand Lust, alternative Regelsätze zu pflegen, die man dann als Ausgangsbasis für andere Karten verwenden kann. Z.B. eine Straßenkarte.
  • Bessere Benutzeroberfläche: Die Listendarstellung in Composer ist zwar übersichtlicher als Befehlsdateien, aber das Zusammenstellen eines Kartendesigns ist immer noch eine reichlich komplexe Aufgabe. Vielleicht hat jemand eine Idee, wie man die Benutzeroberfläche für solche Aufgaben angenehmer gestalten kann, so daß mehr Übersicht entsteht und Regeln leichter editiert werden können?
  • Unterstützung für Routing: Fehlt in Composer komplett, da es für meine Zwecke nicht erforderlich ist und ich mich da nicht auskenne. Es könnte aber interessant sein, auch Routinginfos in einer graphischen Oberfläche zu konfigurieren und mkgmap damit zu steuern. Damit könnte auch dieses Thema deutlich einfacher werden - aber zuerst müßte es mal jemand austüfteln.

Oder hast Du vielleicht noch andere Ideen, was Du gerne damit anstellen würdest?

       Nop

Hallo Nop!

für die Erstellung unterschiedlicher Kartenstile wäre es sinnvoll, wenn man in OSMC soetwas wie “Kartenstil laden / öffnen” und “Kartenstil speicher (unter)” hätte, damit man verschiedene Kartenstile einfacher verwalten kann.

Andererseites: ich bin der Meinung, dass mit Wanderern und Radfahrern (openmtbmap) die größten Zielgruppen für Garmin-GPS-Geräte abgegrast sind. Ich hatte mich mal kurz mit einer ICAO-artigen Karte versucht. Aber für mich hat’s dann die OSMC-Wanderkarte und die All-in-One auch getan… Das ist ja echt unglaublich umfangreich und komplex… Man kann wirklich nur den Hut ziehen vor Leuten, die Rendering-Regeln erstellen und pflegen.

Eine Straßenkarte für Autos ist wohl nur in Kombination mit Routing richtig sinnvoll.

Bis dann
Johannes

Hallo Nop,

mein Style habe ich dahin optimiert, dass es für Reiseradler bzw. Tourenradler hilfreich sein könnte. Das Problem ist, wie Johannes schon anspricht, dass es keine einfache Möglichkeit gibt, zwischen verschiedenen Styles zu wechseln, bzw. ich nicht weiß, welche Dateien benötigt werden. Da würde es mMn auch schon reichen, wenn man irgendwo exportieren drückt, und der Composer dann die wesentlichen Einstellungsdateien, die den Style betreffen in einer gezipten Datei irgendwo ablegt und man beim importieren über einen Öffnen-Dialog eine solche zip-Datei wieder einbinden kann.

Auf meiner wiki-Seite hab ich diesen Style auch veröffentlicht. Bei den Styles wäre evtl. eine Unterseite auf der Composer-Wiki-Seite sinnvoll, wo man die sammeln kann.

@Johannes: Es müssen mMn nicht unbedingt neue Kartennutzergruppen erschlossen werden. Es spricht ja auch nichts dagegen, wenn es 3 verschiedene Wanderkarten gibt oder 4 verschiedene Radfahrerkarten. Jeder Nutzer hat seine individuellen Bedürfnisse an eine Karte.

Hallo

ich kann mich den beiden vorherigen Beiträgen nur anschließen. Es wäre schön, wenn man einen “erarbeiteten” Style einer Karte exportieren / importieren könnte. Das würde zu einem Austausch von Styles führen /hoffentlich), wenn diese unter der Composerseite archiviert würden.

MfG
Achim

Ps.: Der interaktive Modus der RWK ist super. Als Anregung noch ne Seite http://osmtools.de/easymap/index.php?lang=de&page=editor Das Polygonfeature ist zum Erstellen von Rundrouten super. Leider kann man keine Zwischenpunkte einfügen wie bei der RWK… Die “gemeinsamen” Features wären super.

Ps: Aighes ich habe mal von Deiner WikiSeite die Süddeutschlandkarte runtergeladen und in Glopus geladen. Sieht gut aus. Die rose bzw. Lachsfarbenen Ortschaften sind natürlich Geschmacksache. Soll das so sein, oder wird das nur von Glopus so gerendert? In der Reit und Wanderkarte sind in den Ortschaften die Strassen schwer erkennbar. Das ist bei Dir OK, super Danke! Fehlt nur noch dier Style-Austasuchmöglichkeit!

Hallo!

Ich hab’ mir auch schon die Frage gestellt, ob sich so eine Art Stil-Auswahl einzubauen lohnt. Eure Rückmeldungen beantworten diese Frage wohl :slight_smile:

Allerdings: Wie müßte sowas aussehen? Mit dem Austausch der Renderregeln ist es nicht getan, man braucht mindestens noch unterschiedliche Datenverzeichnisse, da die Daten die mit dem einen Regelsatz erstellt wurden nicht auf den anderen passen. Heute erreicht man eine Kombi am sinnvollsten mit zwei Composer-Installationen, denen man ein gemeinsames Input-Verzeichnis gibt. Wie würdet Ihr mit so einem Feature arbeiten wollen?

Was den Anwenderkreis angeht - ich glaube auch wenn es für ein Thema schon eine gute Karte gibt, ist es immer noch Geschmack was einem am Besten gefällt. Das habe ich bei routingfähigen Karten gemerkt. Überhaupt nicht mein Thema, aber ich habe für meine Navi doch ein paar Kleinigkeiten anders gebraucht - und schon generiere ich sie wieder selber. Ich denke viele Leute würden gerne die eine oder andere individuelle Änderung machen, wenn der Aufwand nicht so gewaltig hoch wäre.

bye
Nop

Hallo,

ich würde die einfache, von mir oben beschriebene Weise (zippen der Styledaten) nehmen. Beim Import kommt dann eine Meldung, indem man ein neues Datenverzeichnis anlegen kann. Bspw. über den Speichern-Dialog. So steht es dem Anwender frei, ob er ein neues Verzeichnis anlegt, oder das alte überschreibt.
Einziges “Problem” its dann der Chache der Höhendaten. Diese liegen ja auch im Datenverzeichnis und müssten dann mehrfach vorhanden sein, was unnötig Speicherplatz frisst. Evtl. könnte man diese in das Input-Verzeichnis auslagern.

Das wäre meiner Meinung die einfachste Variante, lediglich den Aufwand des Auslagerns des Caches kann ich nicht einschätzen.

Einen Nutzen sehe ich auf jeden Fall. Gerade am Anfang muss man viel Aufwand in die Styles stecken, bis man heraus hat wie der Hase läuft und man die Wanderkarte umgewandelt hat in eine Radkarte oder Autokarte. Wenn man eine Vorlage hat, die den eigenen Bedürfnissen sehr nahe kommt, fällt ein Großteil dieser Arbeit weg und man muss nurnoch Kleinigkeiten anpassen. Bspw. die Breite der Wege oder die Farben. Aber man muss sich nicht mehr darum kümmern, wie man einen Fahrradweg mit Kopfsteinpflaster anders rendert als einen mit Asphalt.
Also mMn sinkt dadurch die “Hemmschwelle” sich die Karten seinen Bedürfnissen anzupassen. Zumindest, wenn es ein paar Styles gibt.
BEDINGUNG dafür wäre aber eine zentrale Sammelstelle für die Style-Daten. Ansonsten kann es noch so einfach sein, wenn man die Style-Daten nicht findet, bringt das alles nichts;-)
Hier würde aber auch schon eine Tabelle im wiki reichen, in der man 1-2 Screenshots oder eine Beschriebung und den Link einträgt.

Hallo Nop!

Ich bin ja nicht der Programmierer und kann den Aufwand garnicht abschätzen, aber wäre es vielleicht möglich, einen Kartenstil-Namen zu vergeben, der dann in den ganzen Dateinamen auftaucht? Oder alternativ dass OSMC für jeden Style einen Ordner anlegt und in diesem dann arbeitet?

Optimal wäre dann natürlich noch eine “purge”-Funktion, damit man überflüssige Dateien oder einen bestimmten Kartenstil loswerden kann.

Bis dann
Johannes

Es wäre eine Möglichkeit, mehrere Stile komplett zu integrieren und dann sagen wir einfach mit einer Drop-Down-Box umzuschalten. Das hat aber wiederum den Nachteil, daß sie dann ganz eng verheiratet sind. Momentan kann man Stile einfach durch Kopieren/Tauschen von ein paar Dateien von Hand “exportieren”, das wäre dann nicht mehr möglich.

In diese Richtung hatte ich auch schon gedacht. Mir kam allerdings der Einfall, die Style-Einstellungen in das jeweilige Data-Verzeichnis zu integrieren. Dann bräuchte es eine ListBox, wo man die entsprechenden Order angibt, in denen Einstellungen vorhanden sind (alternativ alle Order im Composer-Verzeichnis durchsuchen) und diese dann in einer DropDownBox auf der Hauptseite auswählbar machen.

Dann spart man sich auch eine Import/Export-Funktion. Es reicht, wenn man zum Export einen Leeren Ordner einen entsprechenden Namen gibt und dort die Einstellungsdaten reinopiert. Dann noch für das Internet einpacken. Beim Import muss nurnoch ausgepackt werden.

Nicht ganz. Mit einem Stil muß man auch noch die Icons austauschen.

Momentan überlege ich mir, ob es nicht sinnvoll ist, für den Austausch von Stilen einen zweiten Programmaufruf anzubieten, nennen wir ihn mal Stilmanager. Wenn Du dieses Programm startest, kriegst Du eine Liste von Stilen und kannst zwischen verschiedenen Stilen hin- und herschalten. Wenn Du Composer aufrufst, siehst Du immer nur einen Stil.

Das hätte den Vorteil, daß alle Anwender, die nur einen Stil bearbeiten, sich nie mit dem Thema beschäftigen müssen. Firefox macht das mit seinem Profilmanager so ähnlich - man kann verschiedene Benutzerprofile verwalten, aber die meisten Leute haben den Profilmanager noch nie gesehen und nutzen FF einfach so.

Die Icons hatte ich jetzt zu en Style-Einstellungen gerechnet.

Ich denke mit so einem extra Manager ist es wie mit den Kanonen und Spatzen…Das bringt meiner Meinung für den Anwender keinen Mehrwert.

Meine obige Methode hätte den Vorteil das man einzelnen Jobs evtl. eine Darstellung zuweisen könnte auch über DropDown. Das würde auch gut mit der Warteschlange harmonieren. Ich weiß aber nicht, wie häufig das genutzt werden würde und ob das einen eventuellennen Mehraufwand beim Programmieren rechtfertigt.
Auch weiß ich nicht ob es einfach umsetzbar wäre, den Style ohne einen Neustart des Composers zu ändern. Das wäre ja die Vorraussetzung dafür, dass man den Style im Composer ändern kann. Das kann ich aber nicht absehen, weil ich nicht weiß, wie du das implementiert hast.

Über einen Extra Manager geht es sicherlich auch, fände ich als Anwender aber umständlich…

Hallo Nop,

so eine leicht zu bedienende Oberfläche zur Erstellung verschiedener Karten ist mit Sicherheit eine super Sache, aber dazu ist es wohl wichtig, über das Thema “mkgmap” sehr detailliert Bescheid zu wissen.
Ich persönlich bin leider nur in der Lage mit mkgmap eine Standardkarte (default style) zu erzeugen, allenfalls mit ein paar kleinen Modifikationen. Ich staune immer über die sehr bunten und differenzierten Karten, wie z.B. opencyclemap oder All in One Garmin Map und frage mich, wie man diese generell erzeugt.
Hättest du für den Einstieg in das Thema evtl. eine Quelle parat, wo man sich folgende Fragestellungen beantworten kann:
-Welche Linientypen gibt es überhaupt?
-Welche Linien sind routingfähig und welche nicht?
-Wie sehen die Linien ohne Typ-File aus und wofür verwendet Garmin sie standardmäßig?
-Welche POIs gibt es überhaupt und wie sehen diese ohne Typfile aus?
-Welche exakten Auswirkungen haben die Angaben zu roadclass und roadspeed in mkgmap auf das routing im Gerät?
-Zusätzlich Richtungspfeile an Einbahnstraßen sollen möglich sein. Braucht man dazu overlays und wie erstellt man diese?

In dem default style von mkgmap haben z.B. track, cycleway, footway und path alle denselben Linientyp zugewiesen. Wie würde man sowas weiter differenzieren können, also dass z.B. wie bei Mapnik die Radwege blau gepunktet und die Fußwege rot gepunktet dargestellt werden?

Gruß Ralf

Eine einheitliche Quelle gibt es nicht - man muß sich diese Infos aus verschiedensten Quellen und teilweise aus dem Sourcecode von mkgmap zusammensuchen.

Darum habe ich ja grade Composer geschrieben, damit nicht jeder diese Details kennen muß, sondern nur noch einer, der das es dann Composer beibringt, wie man es richtig umsetzt.

-Welche Linientypen gibt es überhaupt?
Findest Du in den Objektlisten von Composer oder vom Online TYP Editor

-Wie sehen die Linien ohne Typ-File aus und wofür verwendet Garmin sie standardmäßig?
-Welche POIs gibt es überhaupt und wie sehen diese ohne Typfile aus?

Das ist für jedes Gerät ein wenig unterschiedlich. Ist aber nicht wesentlich, man kann sie ja fast alle ändern.

-Welche Linien sind routingfähig und welche nicht?
-Welche exakten Auswirkungen haben die Angaben zu roadclass und roadspeed in mkgmap auf das routing im Gerät?
-Zusätzlich Richtungspfeile an Einbahnstraßen sollen möglich sein. Braucht man dazu overlays und wie erstellt man diese?

Die Antworten auf diese Frage kenne ich nicht. Einbahnstraßenpfeile würde ich in Composer mit einem Overlay mit Pfeil-Bitmap als Muster machen.

Mit Composer: Einfach zusätzliche Renderregeln mit anderen Kartenobjekten anlegen. Das Standardlayout von Composer tut genau das sehr ausführlich.

Nach einigem Grübeln bin ich zu dem Schluß gekommen, daß es definitiv ein zusätzlicher Stilverwalter sein muß.

  • der Normalbenutzer muß sich nie mit verschiedenen Stilen beschäftigen
  • wesentlich weniger fehleranfällig
  • Hilfsfunktionen möglich, z.B. Erkennung ob ein Stil verändert wurde oder einfach überschrieben werden kann

Bei direktem Einbau gibt’s einige Probleme wie

  • manche Dinge sind ziemlich haarig, z.B. müßten alle Icons mit gleichem Namen irgendwie umbenannt werden - oder alle Icons mit vollem Pfad angegeben werden
  • viel Aufwand um einfache Dinge umzusetzen, z.B. Kopieren eines Stils als Vorlage für einen eigenen oder Update eines importierten Stils

Also wenn dann wird’s ein externer Stilmanager. Und wenn ich Euch richtig verstanden habe, dann sollte der mehrere Jobs mit unterschiedlichen Stilen automatisch ausführen können.

bye
Nop

Keep it simple! Ein externer Stilmanager sollte mMn nur Stile Importieren, Exportieren, Löschen, Kopieren und deinen Default-Style wiederherstellen können.

Je mehr du da reinbaust, desto mehr Verwirrung stiftest du damit bei den Anwendern.

EDIT: Bei einer Integration hätte sich sowas angeboten, aber wenn man jetzt aus dem Style-Manager auch Jobs starten kann, befürchte ich zusätzliche Verwirrungen.