OpenStreetMap

Diary Entries in German

Recent diary entries

OpenStreetMap (OSM) hat sich als wertvolles Tool für viele Branchen erwiesen, darunter auch die Hotelbranche. Die Integration von OSM in die Online-Strategie eines Hotels kann dessen Sichtbarkeit und Suchmaschinenoptimierung (SEO) erheblich verbessern. In diesem Artikel erkunden wir, warum OpenStreetMap für Hotel-SEO wichtig ist und wie Hotels von dessen Einsatz profitieren können.

Erhöhte Online-Präsenz für Hotels

Einer der größten Vorteile der Nutzung von OpenStreetMap ist die verbesserte Online-Präsenz. Hotels, die auf OSM gelistet sind, erscheinen in einer Vielzahl von Map-Anwendungen und Diensten, die OSM-Daten nutzen. Das schließt beliebte Apps für Navigation und Reiseplanung ein, welche täglich von Millionen Nutzern verwendet werden. Diese erhöhte Sichtbarkeit kann dazu führen, dass ein Hotel von potenziellen Gästen leichter gefunden wird, was die Wahrscheinlichkeit von Buchungen erhöht.

Lokale SEO-Optimierung für Hotellerie

Lokale Suchmaschinenoptimierung ist für Hotels besonders wichtig. Wenn Ihr Hotel auf OSM gut repräsentiert ist, verbessert es die lokale SEO, da die Plattform von verschiedenen Kartendiensten und Suchmaschinen zur Datenverifizierung genutzt wird. Eine korrekte und detaillierte Darstellung in OSM hilft Suchmaschinen zu verstehen, wo sich Ihr Hotel genau befindet und welche Dienstleistungen es bietet. Dies ist entscheidend, wenn Nutzer nach Hotels in einer bestimmten Region oder Stadt suchen.

Kostenfreie und bearbeitbare Plattform

Im Gegensatz zu vielen anderen Kartendiensten ist OpenStreetMap kostenlos und von einer Community getrieben. Hotels können ihre eigenen Einträge hinzufügen oder bestehende aktualisieren, um sicherzustellen, dass die Informationen immer korrekt und auf dem neuesten Stand sind. Diese Aktualität und Genauigkeit der Daten ist für die SEO-Performance entscheidend. Durch regelmäßige Updates können Hotels ihre Sichtbarkeit in lokalen Suchergebnissen verbessern und sich positiv von der Konkurrenz abheben.

Integration mit Websites und Apps

Hotels können OSM-Karten auf ihren eigenen Websites integrieren, um Besuchern eine visuelle Darstellung ihrer Lage zu bieten. Dies verbessert nicht nur die Benutzererfahrung, sondern stärkt auch die SEO, indem es die Verweildauer auf der Website erhöht und die Bounce-Rate senkt. Interaktive Karten, die den Gästen zeigen, was in der Umgebung des Hotels zu finden ist, können ein entscheidendes Element für die Entscheidungsfindung der Gäste sein.

Verbesserung der Glaubwürdigkeit und des Vertrauens

Ein korrekter Eintrag in OSM kann auch die Glaubwürdigkeit und das Vertrauen in Ihr Hotel stärken. Nutzer, die eine konsistente Information über verschiedene Plattformen hinweg sehen, fühlen sich eher dazu veranlasst, eine Buchung vorzunehmen. Die Transparenz durch genaue und umfangreiche Informationen schafft Vertrauen und kann eine wichtige Rolle in der Kundenentscheidung spielen.

Fazit

Die Bedeutung von OpenStreetMap für die Hotel-SEO kann nicht hoch genug eingeschätzt werden. Die Plattform bietet eine kostengünstige Möglichkeit, die Sichtbarkeit zu erhöhen, die lokale Suchmaschinenoptimierung zu verbessern und letztendlich mehr Gäste anzuziehen. Hotels, die OSM aktiv nutzen und ihre Einträge pflegen, setzen sich in einem konkurrenzreichen Markt durch und verbessern ihre Online-Präsenz signifikant.

Durch die Nutzung von OpenStreetMap können Hotels nicht nur ihre SEO verbessern, sondern auch ein umfassenderes und benutzerfreundlicheres Erlebnis für potenzielle Gäste schaffen. Es ist an der Zeit, die Chancen, die OSM bietet, voll auszuschöpfen.

Weitere Informationen zum Thema finden Sie auf (https://www.mario-vogelsteller.de/seo-hotels/).

Location: 32427, Hahlen, Minden, Kreis Minden-Lübbecke, Nordrhein-Westfalen, Deutschland

OpenStreetMap (OSM) ist mehr als nur ein Kartendienst im Internet: Es ist eine globale Gemeinschaft, die daran arbeitet, freie und editierbare geographische Daten für die ganze Welt bereitzustellen. Als leidenschaftlicher Verfechter der Bedeutung offener Daten und der Gemeinschaftszusammenarbeit möchte ich in diesem Blogartikel teilen, warum ich mich für OSM engagiere und warum ich glaube, dass auch Sie es in Betracht ziehen sollten.

Freie und Offene Daten

In einer Welt, in der geographische Informationen zunehmend kommerzialisiert werden, bietet OSM eine kraftvolle Alternative: Eine freie Karte, die von jedermann verwendet und bearbeitet werden kann. Diese Offenheit fördert nicht nur Innovation und Kreativität, sondern stellt auch sicher, dass diese wichtigen Daten dort verfügbar sind, wo kommerzielle Anbieter vielleicht kein Interesse haben zu investieren. Indem ich zu OSM beitrage, unterstütze ich ein Modell, das Wissen und Ressourcen demokratisiert, was meiner Überzeugung nach für eine gerechtere Welt unerlässlich ist.

Community und Zusammenarbeit

OpenStreetMap ist das Produkt einer engagierten Gemeinschaft von Freiwilligen rund um den Globus. Diese Gemeinschaft ist vielfältig: Sie umfasst nicht nur Kartographen und Geografen, sondern auch Menschen aus allen Bereichen des Lebens, die ihr lokales Wissen einbringen. Durch meine Beteiligung an OSM habe ich nicht nur die Möglichkeit, zur Karte beizutragen, sondern auch von anderen zu lernen und dauerhafte Verbindungen aufzubauen. Diese Zusammenarbeit auf globaler Ebene stärkt mein Gefühl der Zugehörigkeit und zeigt mir, dass meine Beiträge, egal wie klein sie sind, einen Unterschied machen.

Bildung und Empowerment

Die Arbeit mit OSM hat auch einen starken Bildungsaspekt. Indem Menschen lernen, wie sie Karten lesen und bearbeiten können, erwerben sie wichtige technische Fähigkeiten und ein tieferes Verständnis ihrer Umgebung. Diese Fähigkeiten sind besonders in Entwicklungsländern von unschätzbarem Wert, wo Zugang zu präzisen Kartenmaterialien das Potenzial hat, das tägliche Leben und die Entwicklung der Gemeinschaft zu verbessern. Mein Engagement bei OSM ermöglicht es mir, Teil dieses positiven Wandels zu sein.

Resilienz und Katastrophenhilfe

Ein vielleicht weniger offensichtlicher, aber ungemein wichtiger Aspekt von OSM ist seine Rolle bei der Katastrophenhilfe. Freiwillige aus der OSM-Community haben wiederholt gezeigt, wie schnell sie auf Naturkatastrophen reagieren können, indem sie aktuelle, detaillierte Kartendaten bereitstellen, die für Rettungs- und Hilfsaktionen entscheidend sind. Diese Kapazität zur schnellen Reaktion macht OSM zu einem unverzichtbaren Werkzeug in Krisenzeiten. Indem ich mein Wissen und meine Fähigkeiten beisteuere, fühle ich mich als Teil einer globalen Anstrengung, Leben zu retten und Gemeinschaften wieder aufzubauen.

Einladung zum Mitmachen

Meine Erfahrungen mit OpenStreetMap sind durchweg positiv und erfüllend. Ich lade Sie herzlich ein, sich uns anzuschließen, egal ob Sie ein passionierter Kartograph sind oder einfach nur Interesse daran haben, Ihre lokale Gemeinde auf der Karte sichtbar zu machen. Jeder Beitrag zählt und hilft, die Welt ein bisschen besser zu verstehen und zu gestalten.

Ich engagiere mich für OpenStreetMap, weil ich glaube, dass offener Zugang zu geographischen Informationen die Welt transparenter, gerechter und vernetzter macht. Wenn auch Sie an diese Vision glauben, würde ich mich freuen, Sie in der OSM-Gemeinschaft willkommen zu heißen. Lassen Sie uns gemeinsam die Welt kartieren!

Location: 32427, Hahlen, Minden, Kreis Minden-Lübbecke, Nordrhein-Westfalen, Deutschland

Am 24.04.2024 fand für die Touristiker des Saarlandes der zweite Teil eines Seminars zum Thema Route 3.0 & OpenStreetMap statt. Auf Einladung durch Klaus Wallach von der Tourismus Zentrale Saarland nahmen mit Barthwo und mir auch zwei saarländische Mapper an dem von Thomas Froitzheim durchgeführten Seminar teil. Motiviert wird das Seminar durch die neue Richtlinie Route 3.0 des Deutschen Tourismusverband (DTV).

Ziel des Seminars war es, die Touristiker mit dem Konzept OpenStreetMap bekannt zu machen und zur Kontrolle der richtigen Hinterlegung von Wander- und Radtourrelationen in OSM zu schulen. Dabei konnten die Touristiker sehen, dass sehr viele der Routen bereits von fleißigen Mappern in OSM hinterlegt wurden. Im Rahmen der Schulung kamen Tools wie BRouter-Web, GPX Viewer sowie WayMarkedTrails zum Einsatz. Anhand dieser Tools können die Touristiker nun:

  • die aktuellen .gpx-Dateien bestehender Routen aus ihren Datensystemen mit den Relationen in OSM vergleichen, um fehlende oder fehlerhafte Relationen zu identifizieren, sowie
  • ohne Vorerfahrung mit wenigen Klicks .gpx-Dateien erstellen, die bei kurzzeitigen temporären Umleitungen den Touristen zur Verfügung gestellt werden können.

Die meisten Touristiker kamen im Rahmen des Seminars zum ersten Mal mit der Datenstruktur von OpenStreetMap in Kontakt. Da das Anlegen oder Modifizieren von Relationen durch unerfahrene Nutzer viele Risiken birgt, wird eine Lösung unter Zuhilfenahme der Mapper-Community benötigt, anstatt den Touristikern das recht komplexe und zeitaufwendige Thema Relationen aufzubürden.

So stellte Thomas Froitzheim auch eine uMap vor, die von der Mapper-Community der Mittelweser- und Minden-Region erarbeitet wurde und bei den lokalen Touristikern auf reges Interesse stieß. Die uMap bietet ein benutzerfreundliches Kommunikationswerkzeug, über das Fehler in Relationen gemeldet werden können, ohne dass die Touristiker fortgeschrittenes Wissen in OSM-Relationen haben müssen. So können erfahrene Mapper aus der Region die Relation basierend auf Meldungen der Touristiker, die in der uMap eingetragen werden, überarbeiten. Umgekehrt herum können auch Mapper Rückmeldungen zu Beschilderungen oder Schäden der Wege als Medien in die uMap eintragen. Diese können dann wiederum von den Betreibern genutzt werden, um die Qualität der Wege selbst zu steigern. Darüber hinaus lassen sich Gegebenheiten durch die Farbgebung optisch gut hervorheben und über den uMap-Link leicht mit den Gemeinden teilen, so Thomas Froitzheim. Es ergibt sich eine Win-Win-Situation für alle Beteiligten.

Die saarländische Mapper-Community strebt an, in Zukunft enger mit den Touristikern des Landes zusammen zu arbeiten und eine ähnliche uMap für das Saarland zu entwickeln. Es sind sehr schöne Entwicklungen, dass OpenStreetMap im Tourismus mittlerweile als Standard etabliert ist.

Posted by Infra-Simon on 14 March 2024 in German (Deutsch).

Hallo zusammen,

ich habe auf der Arbeit die Aufgabe das Parken in Frankfurt mithilfe des Rapid Editors zu taggen. Dafür möchte und soll ich so präzise wie möglich vorgehen. In vielen Straßen kommt es aber vor, dass verschiedene Parkrichtlinien oder Ausrichtungen bestehen. Außerdem sind einige Straßen sehr lang in OSM.

Eine Möglichkeit ist, die Straßen mithilfe eines Punkts zu teilen, um verschiedene parktags einzufügen. Das zerstückelt aber oft die Straßen und es entstehen kleine Teilstücke mit verschiedenen ID’s. Die zuvor eingefügten Attribute bleiben aber bestehen.

Jetzt ist die Frage, welche Folgen es hat, die Straßen aufzuteilen, um präzise Parkangaben tätigen zu können, oder ob das keine wirkliche Rolle spielt. Viele Straßen sind ja sowieso schon sehr aufgestückelt.

Über eine Antwort würde ich mich sehr freuen.

Gruß Simon (Infra-Simon)

Location: 60322, Nordend West, Innenstadt 3, Frankfurt am Main, Hessen, Deutschland

Moin liebe Community, ab dem 20.03.2024 bis zum 01.04.2024 werde ich mich in Nienburg aufhalten. Folgende Hinweise werde ich dann bearbeiten:

Hinweis 3983162 - Fichtestraße 32, Nienburg

Hinweis 3678091 - Lemkerstr. 3d, Nienburg

Hinweis 3208133 - Verdener Landstr. 179, Nienburg

Hinweis 3955130 - Krähe/Langendamm

Ebenfalls werde ich mit StreetComplete arbeiten.

Solltet Ihr noch irgendwelche Hinweise haben, dann schreibt mir gerne hier auf OSM.

Habt einen angenehmen Tag, Daniel (DanieCeBus)

Location: 52.645, 9.218
Posted by GUFSZ on 25 February 2024 in German (Deutsch).

Ich bin ziemlich viel von diesem Routennetzwerk mit dem Fahrrad abgefahren. Es stellen sich dabei einige Probleme. Ausgangspunkt war, dass ein User einen Teil dieses Routennetzwerk von der Regionalparkzeit zusammengeklickt hat und mit schon bestehenden Daten vermischt hat. Das Netzwerk bekam in der Datenbank den Namen “Regionalpark Routennetz südlich des Mains”. Aber die eingetragenen Wege stimmten nicht mit den Angaben von https://www.regionalpark-rheinmain.de/ überein. Es war wesentlich mehr in OSM erfasst. Also habe ich mir OTG angeschaut, ob ich die Struktur, die der Regionalpark beschreibt, entdecke. Das ist nicht möglich.

Es gibt zwei Beschilderungen. Eine Beschilderung, die der FGSV-Beschilderung für Fahrräder angelehnt ist und eine eigene Regionalparkbeschilderung. Hie und da stehen diese Beschilderungen nebeneinander und widersprechen sich.

Weiter gibt es Routen, die im Landesfahrradroutenplaner stehen, aber nicht ausgeschildert sind. In Realität gibt es auch Routen, die ausgeschildert sind, aber nicht im Landesfahrradroutenplaner stehen.

Auf der Seite https://www.regionalpark-rheinmain.de/ wird zwar das Regionalparkprojekt dargestellt. Aber das lässt sich, wie schon geschrieben, schwer in der Beschilderung wiederfinden. Beispiel Regionalpark-Rundroute. Man findet sie problemlos, aber es wird nie klar, ist sie jetzt ein hervorgehobener Teil des Routennetzwerkes oder ist sie ein Teil, der nicht zum Routennetzwerk gehört? Ähnlich die Klimaroute.

Deswegen habe ich das Routennetzwerk wieder zurück umbenannt und fast alles abgefahren, was in der Datenbank war. Dann bin ich auch noch die Wege abgefahren, die im Landesroutenplaner stehen. Falls ausgeschildert, habe ich sie eingetragen.

Dabei musste ich aber feststellen, es gibt einige Abzweige, die weder in OSM, noch im Landesfahrradroutenplaner eingetragen sind. Ich hoffe, dass diese fehlenden Stücke durch andere ihren Weg in die Datenbank finden.

Posted by opasto on 12 February 2024 in German (Deutsch).

Ich, opasto,war altershalber längere Zeit nicht mehr aktiv. Nun wollte ich mich mal wieder einschalten. Also Firefox aufgerufen, Konto OSM aufgerufen, Benutzername und Passwort sind schon voreingestellt, Anmelden: Nun heisse ich plötzlich dan34 und habe mit den dort gezeigten Beiträgen nichts zu tun. Ich bin also mit richtigem Benutzername und meinem dazugehörenden Passwort bei einem falschen Benutzer gelandet. Ist mein Benutzername wegen meiner längeren Abwesenheit freigegeben worden und dan34 hat sich zufällig mit demselben Benutzernamen und Passwort neu angemeldet? Sehr unwahrscheinlich! Anderer Zugang: http://www.openstreetmap.org/ rechts oben ist opasto voreingestellt, gehe zum heimatstandort: Der wird korrekt gefunden. Auch andere Daten über diesen Zugang stimmen. Nun habe ich meinen Eintrag für OSM in Firefox untersucht: Und der lautet jetzt tatsächlich https://www.openstreetmap.org/login?referer=%2Fuser%2Fdan34 Wie kann sowas geschehen?? Nach meiner Erinnerung habe ich mit dan34 nie etwas zu tun gehabt. Ob ich irgendwann mal einen Beitrag von dan34 gelesen habe? Dies übersteigt mein Erinnerungsvermögen.

Posted by Ralf1104 on 9 February 2024 in German (Deutsch).

Hallo, ich habe von der Allianz den Drive Dot. Der zeichnet mir unterschiedliche Fahreigenschaften auf und speichert sie, Seit September 2023 wird auf der Maurener Strasse von Holzgerlingen nach Ehningen ein Stück mit nur 30km/h angezeigt, obwohl da eigentlich noch 100km/ h erlaubt ist. wie wird das geändert??

Mit freundlichen Grüssen,

Ralf

Location: 71088, Baden-Württemberg, 71088, Deutschland
Posted by HeyMissDaisy on 8 January 2024 in German (Deutsch).

Ich habe ein Problem Schäferhund Verein in Not. Ganz ehrlich… OG Rosstal Adresse Fernabrünster Strasse (?), 90574 Rosstal wird von Navi nicht erkannt. (Tesla) , weil die Strasse, nachdem sie in einen Feldweg asphaltiert dann in befestigten Sandwanderweg mündet, keinen Strassennamen mehr hat und auch nichts mehr im Auto anzeigt. Der Schäferhund Verein liegt linker Hand im Wald und man muss an der 2. T Kreuzung nach links abbiegen, aber bis dahin ist man meistens schon iranvorbeigefahren. Da sieht alles gleich aus. Ein großes Problem. Ich wollte einen richtungsweisenden Pfeil einfügen, aber ich scheiterte bereits auf dem Zielpunkt SV - Ortsgruppe Rosstal e.V. , das soll so quer über den Rasenplatz stehen, da wollte ich den Parkplatz und den Übungsplatz kennzeichnen. Kann mir jemand helfen? Wir haben im Mai eine Bundesdeutsche Sportveranstaltung. Wir müssen den Verein so Kennzeichen, das ca. 300 Menschen dort ohne Probleme hinfinden können und wissen, das sie direkt vor dem Vereinsheim parken können.

Ich habs versucht, ich Checks heute gar nicht. Bitte um Hilfe! Gute Nacht, ich packs nicht mehr. Lg, Hey Miss Daisy

Location: 90574, Trettendorf, Roßtal, Landkreis Fürth, Bayern, Deutschland

Heute, beim erstmaligen Versuch des Mappings mittels streetcomplete versuche ich vergeblich, die Funktion der Längenmessung auf einem Smartphone zu aktivieren. Ich nutze ein Fairphone4, das Google ARCore nicht unterstützt. Es funktioniert also nicht. Keine Augmented Reality, keine Entfernung. Ich benutze also eine einfache Variante, um die Breite von Fahrwegen zu bestimmen: die Schrittlänge. Die beträgt bei meiner Grösse durchschnittlich 75 cm. Also einfach die Fahrbahnbreite abgegangen (Achtung, Verkehr!) und dann auf die vollen Meter auf- oder abgerundet. Mehr verlangt die App auch gar nicht: runde Meter.

Man kann es sich auch schwermachen in der digitalen Welt, oder einfach, indem man sich ein wenig unabhängig macht und selber denkt!

Ausgangslage

Unser Kenwood-Autoradio im Wohnmobil mit integrierter Navigation (Kenwood DNX450TR, Doppel-DIN-Format) hat das letzte Kartenupdate 2020 erhalten. Die Karten sind nun schon über 3 Jahre alt und zeigen häufig veraltete Geschwindigkeitsbegrenzungen, und es fehlen auch mal Umgehungsstraßen, Kreisverkehre, etc. Kurz, ein Update steht an.

Die Navigationsfunktion im Gerät ist von Garmin, welches als OEM-Partner von Kenwood die Navigationssoftware bereitstellt. Allerdings ist auf der Garmin-Webseite für OEM-Geräte das DNX450TR nicht mehr gelistet. Es gibt also anscheinend keine Kartenupdates vom Hersteller mehr.

Wir wollen auch während der Fahrt nicht vom Mobilfunknetz abhängig sein, entsprechend sind online-Navigationslösungen (Google Maps, etc) keine Alternative. Zusätzlich hat das Gerät keine gute Smartphone-Integration, daher funktioniert die Nutzung von Offline-Navigation auf dem Android-Telefon nicht zusammen mit dem DAB-Radio. Man kann zwar die Sprachausgabe des Telefons auf dem Autoradio ausgeben, hat dann aber kein Radio. Bei Ausgabe über den Telefonlautsprecher regelt natürlich das Radio nicht ab. Also auch keine zufriedenstellende Lösung.

Das teure Radio entsorgen (~ 1000€ Neupreis, wegen des LKW-Modus in der Navigationssoftware (TR = “truck” im Modellnamen)) und durch z.B. ein Gerät auf Android-Basis ersetzen ist ebenfalls nicht zufriedenstellend.

OpenStreetMap für das Kenwood/Garmin Navi?

Es gibt einige Anbieter von Garmin-kompatiblen Kartensätzen, die Liste aus dem OSM Wiki ist gut gefüllt: https://wiki.openstreetmap.org/wiki/OSM_Map_On_Garmin/Download

Aber

Die meisten der gelisteten Quellen sind optimiert für Hiking, MBT, Ski, Radfahren, Wandern, etc. Rendering ist optimiert für Garmin Handhelds mit Displays, die nur 16/64 Farben darstellen können, etc… Manche haben keine Indexsuche, entsprechend keine Adresseingabe, die aber für eine Autonavigation zwingend funktionieren muss. Die meisten angebotenen Karten haben schlicht einen eher inkompatiblen Hauptfokus.

Die Jagd nach einem geeigneten Kartensatz

Anforderungen sind

  1. Muss überhaupt mit dem Kenwood-Radio funktionieren. Es war zu Beginn nicht klar, ob die Garmin-Software nur von Kenwood signierte/verschlüsselte Kartendaten lesen kann, oder ob sie mit beliebigen Karten im Garmin-Format funktioniert.
  2. Navigierbar, Beachtung von Gewichts-/Breiten-/Höhenbeschränkungen
  3. Funktionierende Adresssuche
  4. Kein Hochkontrast-Stil für Displays mit 160x320x4bit. Diese sehen auf dem Radiobildschirm extrem überladen und unübersichtlich aus.
  5. Keine Höhenlinien. Die überfrachten die Anzeige der eh schon dichten Karten weiter
  6. Nach Möglichkeit keine Anzeige von Dingen, die für die PKW/LKW-Navigation unwichtig sind. Keine Anzeige von individuellen Bäumen, die in manchen Innenstädten erfasst sind. Keine Fuß- und Radwege, Treppen. Anzeige diverser landuse-Tags ist auch nicht unbedingt nötig.
  7. Übersichtliche Anzeige von Autobahnen und Bundesstraßen auf niedrigen Zoomstufen

Der beste Treffer bislang sind die Karten von freizeitkarte-osm.de. Das Rendering ist angenehm dezent, im Stile des offiziellen OSM Tileset. Keine Gebäudeumrisse in knalligem Signalrot, Felder in Grellgelb, etc. Spoiler: Es ist allerdings schon fast zu dezent. Insbesondere im niedrigen Zoombereich werden von der Navigationssoftware keine Straßen angezeigt. Somit kann man bei der Routenübersicht nach Adresseingabe nicht sinnvoll aus den vom Navi generierten Alternativrouten wählen. Man sieht schlicht die Straßen nicht.

OSM-Karten auf das Navi übertragen

Ein erster Versuch, die Navi eine aus OSM-Daten erstellte Karte laden zu lassen schlug fehl. Einfach die Karten als Datei /Garmin/gmapsupp.img auf der SD-Karte abzulegen führte nicht zum Erfolg.

Ein zweiter Ansatz führte zum gewünschten Ergebnis: Die Micro-SD vom Gerät initialisieren lassen (In der Navigationssoftware das Kartenupdate im Einstellungsmenü auswählen), und dann mittels der Software Garmin Express mit der OEM-Karte befüllen lassen. Danach die von Garmin-Express erstellte Kartendatei /Garmin/gmapsupp.img durch eine OSM-Karte ersetzen. Die Navigationsoftware lud die OSM-Karte anstatt der Originalkarte.

Ein erster Erfolg. Das Gerät ist in der Lage, mit offenen Tools erstellte Garmin-Karten zu laden und zu verwenden. Es gibt keine Signaturprüfung, die nur vom OEM zugelassene Karten erlaubt.

Analyse der OEM-Karte

Die OEM-Karte (Im Gerät unter “myMaps” angezeigt als “OEM CN Europe NTU 2020 ALL North” und “OEM CN Europe NTU 2020 ALL South”) liegt in 2 Teilen vor, Nordeuropa unter /Garmin/gmapsupp.img, und Südeuropa unter /Garmin/Map/gmapsupp.img. Diese Zuordnung wurde mit Hilfe des gimginfo-Tools gefunden, welche die genannten Namen in den Dateiheadern gefunden hat.

Garmin-Express legt zusätzlich noch eine Reihe anderer Dateien ab, wie z.B. die Spurassistenz-Bilder. All diese Informationen werden in der XML-Datei /Garmin/GarminDevice.xml abgelegt:

Hier ein Auszug. Interessanterweise wird Nordeuropa als Typ “PreProgrammedMaps” registriert, Südeuropa weiter unten in der Datei als “SupplementalMaps”. Außerdem spezifiziert die Datei 2 Dateien des Typs “PreProgrammedMaps”: “gmapsupp”, und “gmapsup1”, allerdings schreibt Garmin Express nur gmapsupp.img.

  <MassStorageMode>
    <DataType>
      <Name>PreProgrammedMaps</Name>
      <File>
        <Specification>
          <Identifier>IMG</Identifier>
        </Specification>
        <Location>
          <Path>Garmin</Path>
          <BaseName>gmapsupp</BaseName>
          <FileExtension>img</FileExtension>
          <Extensions>
            <dtlx:DataTypeLocationExtension>
              <dtlx:ExternalPath>Garmin/</dtlx:ExternalPath>
            </dtlx:DataTypeLocationExtension>
          </Extensions>
        </Location>
        <TransferDirection>InputOutput</TransferDirection>
      </File>
    </DataType>

Diese XML-Datei ist recht gut lesbar und erweiterbar. Man kann im DataType PreProgrammedMaps weitere Dateien hinzufügen, indem man einfach weitere <File>-Blöcke hinzufügt.

Weitere Karten beziehen und registrieren

Ich habe mir Karten für 14 Länder in Mittel- und Westeuropa in der Version vom Dezember 2023 von freizeitkarte-osm.de geladen, und diese in 4 Pakete nahe 4GiB (dem FAT32-Dateigrößenlimit) gepackt.

Zur Berechnung der Packung in möglichst wenige Dateien unter 4GiB diente das Python-Paket binpacking. Das eigentliche Kombinieren der Einzelkarten anhand der berechneten Packung übernahm dann die CLI-Version von GMapTool

Damit ergaben sich 4 Dateien, benannt gmapsup1.img, gmapsup2.img, gmapsup3.img, und gmapsup4.img.

Diese in der /Garmin/GarminDevice.xml, in der Sektion PreProgrammedMaps abgelegt und auf die Micro-SD kopiert. Ausschnitt:

      <File>
        <Specification>
          <Identifier>IMG</Identifier>
        </Specification>
        <Location>
          <Path>Garmin</Path>
          <BaseName>gmapsup2</BaseName>
          <FileExtension>img</FileExtension>
          <Extensions>
            <dtlx:DataTypeLocationExtension>
              <dtlx:ExternalPath>Garmin/</dtlx:ExternalPath>
            </dtlx:DataTypeLocationExtension>
          </Extensions>
        </Location>
        <TransferDirection>InputOutput</TransferDirection>
      </File>
      <File>
        <Specification>
          <Identifier>IMG</Identifier>
        </Specification>
        <Location>
          <Path>Garmin</Path>
          <BaseName>gmapsup3</BaseName>
          <FileExtension>img</FileExtension>
          <Extensions>
            <dtlx:DataTypeLocationExtension>
              <dtlx:ExternalPath>Garmin/</dtlx:ExternalPath>
            </dtlx:DataTypeLocationExtension>
          </Extensions>
        </Location>
        <TransferDirection>InputOutput</TransferDirection>
      </File>

Karte einsetzen

Nach dem Ablegen der Kartendateien auf der Micro-SD, und erweitern der GarminDevice.xml um die 4 neuen Kartendateien werden die OSM-Karten nach dem Einsetzen der Micro-SD vom Navigationssystem erkannt und benutzt. Man kann nun im Menü myMaps zwischen der Originalkarte und den OpenStreetMap-Karten wechseln.

Kartenauswahl

Das Resultat soweit

Kartendarstellung auf regulären Zoom-Stufen soweit akzeptabel. Könnte klarer sein, aber erst einmal nicht schlecht:
Kartendarstellung

Auf Übersichtskarten gibt es keine Übersicht:
Es sollte ein Straßennetz erkennbar sein

Ausblick/Nötige Verbesserungen

Das Standard-Rendering der Freizeitkarte-Karten ist nicht für reine Autonavigation optimiert. Es besteht Verbesserungsbedarf:

  • Auf niedrigen Zoomstufen werden keine Straßen angezeigt. Man kann sich also am Bildschirm keine visuelle Übersicht über das Autobahn-/Bundesstraßennetz verschaffen.
  • Auf hohen Zoomstufen werden unnötige Details angezeigt, wie z.B. Rad- und Fußwege

Als nächsten Schritt dann herausfinden, wie man den Stil anpassen kann. Der Stil soll wohl in TYP-Dateien festgelegt sein. Also schauen, wie man den Stil aus den Karten extrahiert, anpasst, und einfügt.

Posted by Robhubi on 11 December 2023 in German (Deutsch).

Unschön, mag ich gar nicht. Mach ich trotzdem manchmal.

Zum Editieren von Objekten einer Objektklasse muss ich sie identifizieren und unterscheiden können. In den meisten Fällen ist der Name dafür ausreichend. Aber nicht immer. Der Name könnte nicht existieren oder er existiert mehrfach im Editiergebiet. Einfachste Lösung: Namen erfinden bzw. auf Unterscheidbarkeit modifizieren.

Einfach ja, aber unsauber. Grundsätzlich ist hier das Wiki sehr klar: im name-Tag soll nur ein real existierender Eigenname stehen und nur der Eigenname [1].

Beispiele für suspekte Eigennamen

Meine konstruierten Namen

Viele Radrouten haben Alternativen, Zubringer und optionale Exkursionen. Nur bei kleinen und einfachen (ohne forward/backward) Routen verwende ich zur Benennung die Rolleneigenschaft [3]. Meist teile ich die Route aber in eine Hauptroute und in eine Alternative Route, mit allen Varianten, Zubringer und Exkursionen, auf. Oft unterteile ich auch die Hauptroute weiter in Etappen, um die Größe der Relationen unter 500 Mitgliedern zu halten.

Zur Unterscheidung der Teilrelationen ergänzte ich bisher die Namen:

Gesamtroute mit: Eigenname + "Master"
    Hauptroute mit: Eigenname

        Hauptroute Teil 1 mit: Eigenname + "Etappe 1"
        Hauptroute Teil 2 mit: Eigenname + "Etappe 2"
        :
    Alternativen, Zubringer ... mit: Eigenname + "Alternative"

Zum Bearbeiten der Relationen sind diese Namen praktisch, aber sauber ist es nicht.

Lösung für namenlose Relationen in JOSM

In der Diskussion zum Proposal [4] hat segubi eine Alternative zu konstruierte Namen vorgeschlagen: die “relation.nameOrder” in JOSM. Mit diesem Schlüssel wird angegeben welche Tags zur Referenzierung der Relationen in Frage kommen. Das erste nicht-leere Element in dieser Liste wird zur Benennung der Relation verwendet.

Zur Liste kommt man im Expert Mode unter Preferences/Advanced Preferences/relation.nameOrder. Die Default Einstellung und meine Änderung ist unten dargestellt:

relationNameOrder

Anwendungsfall Radweg I1

Der Tipp von segubi kam mir bei der Pflege des I1-Radweges gerade sehr gelegen. Der Betreiber nennt diese Route “I1 - Gardasee-Venedig”. Offensichtlich eine beschreibende Benennung, aber kein Eigenname. Diese Route habe ich in eine Hauptroute und eine Alternativroute aufgeteilt und weiters die Hauptroute in 4 Etappen geteilt.

Relation 1607435: I1 Hauptroute. Superroute mit den 4 Etappen als Mitglieder. Relation 16478126: I1 Alternativen. Varianten und Anbindungen, 269 Mitglieder.

Damit gab es mehrere Relationen ohne Namen, aber mit identischer ref=I1. Für eine leicht erkennbare Unterscheidung in JOSM waren zwei Änderungen nötig:

  1. Tag description=<beschreibende Benennung> für die Relationen erstellen
  2. Anpassung der relation.nameOrder - Liste

In der relation.nameOrder - Liste verschob ichdescription von der Position 13 auf die 2. Position - nach dem Namen, aber vor der Ref. Damit wird statt der immer gleichen Ref, die unterscheidbaren descriptions zur Benennung der Relationen verwendet. Der geänderte xml-File für JOSM Vers. 18822:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<config>
    <preferences operation="replace">
        <list key="relation.nameOrder" xmlns="http://josm.openstreetmap.de/preferences-1.0">
            <entry value="name"/>
            <entry value="description"/>
            <entry value="ref"/>
            <entry value="amenity"/>
            <entry value="landuse"/>
            <entry value="leisure"/>
            <entry value="natural"/>
            <entry value="public_transport"/>
            <entry value="restriction"/>
            <entry value="water"/>
            <entry value="waterway"/>
            <entry value="wetland"/>
            <entry value=":LocationCode"/>
            <entry value="note"/>
            <entry value="?building"/>
            <entry value="?building:part"/>
        </list>
    </preferences>
</config>

Die umgereihte Liste (erweitern ist möglich!) kann als XML-File direkt geladen werden. So gut diese Lösung in beim I1 funktionierte, es gibt doch einige Probleme:

  • Key description - wird häufig zur Beschreibung des Elementes verwendet. Ein Nutzungskonflikt mit der Verwendung als “beschreibenden Namen” ist wahrscheinlich
  • funktioniert nicht für benannte Routen - dazu müsste description in der relation.nameOrder-Liste vor dem Namen stehen. Vermutlich wäre das keine gute Idee

Lösung für benannte Relationen in JOSM

Bei benannten Routen habe ich bisher den Eigennamen mit passend Erfundenen ergänzt: Also “Eigenname” + “Hauptroute” oder “Etappe xx” oder “Alternativen” (siehe oben). Alternativ zum hier ungeeigneten description-Tag wäre auch ref_name vorstellbar.

ref_name wird häufig bei Haltestellen verwendet, wenn der Eigenname zur Referenzierung mit externen Datenbanken uneindeutig ist. Z.B: name=”Spielbank” und ref_name=”Bad Wiessee Spielbank”. Von der Struktur her ist es genau das gesuchte: ein beschreibender Name.

Auch die erste Stelle in der relation.nameOrder erscheint mir hier unproblematisch. Die Benennung der Relationen in JOSM mit “ref_name” statt “name” sollte eigentlich immer brauchbar sein.

Nur den ursprünglichen Zweck - die externe Referenzierung - erfüllt es nicht. Stattdessen wird es als eindeutiger Name zur internen Referenzierung verwendet. Der wesentliche Unterschied: die exterene Referenzierung ist offiziell und somit verifizierbar, die interne ist es nicht, da sie meine Erfindung ist.

Eine wirklich total saubere Lösung sehe ich nur mit einem neuen Tag erfüllbar:

descriptive_name = <beschreibender Name>

  • Kein Bedeutungskonflikt mit bestehenden Tags

  • Verifizierbarkeit ähnlich description

  • Kann ohne Nebenwirkungen an erster Stelle in der relation.nameOrder-Liste stehn

Eigennamen wie “Dorfkapelle Krusdorf” wären dann Geschichte. Hoffentlich.

Resümee

Für Relationen ohne Namen ist das Tag description eine akzeptable Möglichkeit, Teilrelation unterschiedlich zu benennen und im Editor zu unterscheiden. Für Relationen mit Namen habe ich mit den bestehenden Tags keine saubere Lösung gefunden. Am besten scheint mir noch ref_name dafür geeignet zu sein.

In beiden Fällen - sowohl bei description als auch bei ref_name - wird die ursprüngliche vorgesehene Bedeutung etwas verschoben. Ich finde es noch akzeptabel, aber das wird vermutlich nicht jeder so sehen.

Eine wirklich saubere Lösung wäre ein neuer Schlüssel, wie z.B. “descriptive_name” um den häufigen Missbrauch der Eigennamen einzudämmen, ohne das Editieren zu erschweren.



[1] OSM Wiki Namen: https://wiki.openstreetmap.org/wiki/DE:Namen

[2] OSM Wiki Public transport: https://wiki.openstreetmap.org/wiki/Public_transport

[3] OSM Wiki Roles for recreational route relations: https://wiki.openstreetmap.org/wiki/Roles_for_recreational_route_relations

[4] Proposal: Use description instead of name for route relations