The key “name” is one of the 10 most frequently used characteristics of objects - according to Taginfo 100 million times. It is probably also the tag with the most errors. A random sample in my neighbourhood showed an error rate of 8.4% (N=1092). Possible reasons:

1. lack of knowledge
2. misunderstanding
3. tag missing

The proposal relates to point 2, possible misunderstandings regarding the meaning of the “name” tag.

Current Wiki structure

The main article names lists 14 different keys of the proper name, differentiates them from each other and from non-proper names and gives many examples. The article is quite extensive with 29k characters.

Of the 14 keys, 5 keys do not have their own wiki page: int_name, loc_name, nat_name, reg_name and nickname.

The article on the key name is similar to the main article names, only somewhat shorter. It is still quite extensive with 18k characters. All other articles are short.

Issues Main article “names”

Readability.

The text is very extensive and therefore requires perseverance. However, it deals with all aspects of name keys in detail and consistently. Many examples illustrate the basic idea.

Issues key:name

Readability, redundancy, clarity.

The text for the key name is very long at 18k characters, the essentials are lost in the sea of words. Much of it is a repetition of information that is already available elsewhere:

• The “values” section is almost completely contained in the main article.
• The “Variants” table is already completely contained in the main article.
• The table of language subkeys covers more than 3 screen pages and is also fully covered on the “Multilingual names” page.
• The sections “Road names” and “Additional data” are also already included in the main article. Only the sentence with “strapline” is supplementary.

In addition to the high redundancy, the text is also blurred. The core - the proper name - is not mentioned at all. The explanations lead to problematic statements.

An example. Quote:

“sources of primary names: The most prominent name on a sign posted on the feature itself, especially for a feature in the built environment”

So this building should be tagged with name=Toaletter?

(zoom)

Clearly wrong, as it contradicts the main article.

A second example. Quote:

As a rule of thumb, the primary name would be the most obvious name of the feature, the one that end users expect data consumers to expose in a label or other interface element.

This statement is nowhere to be found in the main article. The wording is also ambiguous, are we tagging according to reality or according to the wishes of the data consumer? The latter seems to apply here:

(zoom)

The data consumer may be happy with the name “Green Walk (Easy Access)”, but it is not a name in the sense of the main article.

Another example. Quote:

This key is set to the primary name of the feature in the real world.

I read it like this: “primary name is the most commonly used name for that feature”. “primary” here denotes an order if there are several names. However, it says nothing about which names are involved. Names are multifaceted: class name, collective name, mass name, proper name … which name is meant?

The sentence should read: This key is set to the proper name of the feature in the real world. Or also: This key is set to the primary proper name of the feature in the real world.

Name “Toaletter” in the example above is then clearly excluded as a class name for the name key. In addition to class names, name-like descriptions are often misunderstood as proper nouns. No wonder, really, if the proper name is not defined as a term.

The term “primary name” is not used anywhere in the main article. The entire main article revolves around the term proper name, but it is only used explicitly a few times. It is strange why it remains completely unmentioned as a central term in the entire key:name article.

Did the authors understand the name as a synonym for the proper name? Or have I lost my way in the labyrinth of foreign language, everyday usage, grammar and linguistic philosophy?

One thing is for sure: I’m not the only one. The many errors in tag names scattered around the world are a clear indication.

Goal

Clarity.

• Focus article key:name on the essentials, maximum text volume 1 to 2 screen pages
• Intensive integration of the main article by means of references
• Pay attention to translatability

Here is a text proposal as a starting point.

Non-goal

Change to the scope of meaning of the key name, neither restricting nor expanding. Reference is the main article names.

… and you?

What is your opinion: do you think the proposed restructuring makes sense?

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

• Wanderweg 786 Viele ÖAV-Wanderwege haben keinen Namen, name=Wanderweg XXX ist sicher kein Eigenname
• Dorfkapelle Krusdorf Kategorie + Ort ist meist kein Eigenname. Hier ist es definitiv nicht korrekt, der Eigenname ist “Maria von den Engeln”
• Bus 600: Leibnitz Postamt => Graz Don Bosco Bahnhof Ein vollständig konstruierter Name. Das Public Transport Schema [2] hat das name-Tag vollständig gekapert
• Murradweg Verbindungsrouten (AT) der Eigenname wird mit der Ergänzung zu einem beschreibenden Namen
• Apotheke, Fußballplatz, Toilette Gattungsnamen sind kaum jemals Eigennamen. Spaßig die Diskussion Is name=Toilet even theorethically valid for amenity=toilets?

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:

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

Die Graphenintegrations-Plattform (GIP) ist der zentrale, österreichweite Verkehrsgraph für alle Verkehrsformen inkl. Schiffe, U-Bahnen, Seilbahnen, Busse, KFZ, Radfahrer, Fußgänger etc.

Eine der markantesten Anwendung ist die intermodale Verkehrsauskunft für ÖV, MIV, Rad und Fußverkehr. Z.B. können Fußgänger die letzten Meter zwischen Haltestelle und Ziel durch Parkwege, Durchgänge etc. geroutet werden.

Diese amtlichen Daten werden in regelmäßigen Intervallen aktualisiert und unter CC-BY-4.0 allen Interessenten zur Verfügung gestellt. Die Quelldaten bleiben dabei im Besitz der Eigner (z.B. ASFINAG, ÖBB, Bundesländer …), es findet nur ein Abgleich der relevanten Daten statt.

Naturgemäß sind die höherrangingen Verkehrsdaten bevorzugt und inzwischen auch vollständig erfasst. Bei den Radrouten beginnt es sich auszudünnen, zur Zeit sind zumindest die Landesradwege österreichweit erfasst und als OGD verfügbar. Die Radrouten der Tourismusverbänden fehlen noch überwiegend.

Völlig blank ist die GIP bei den Wanderwegen. Mich wundert das nicht, denn Wanderwege sind eigentlich keine Verkehrswege sondern eher Wege für Freizeit und Sport. Im Gegensatz zu den Seilbahnen ist auch die unmittelbare wirtschaftliche Bedeutung gering.

Interesseneigner Wanderwege

Amtliche Daten zu den Wanderwegen könnte die Finanzierungskette Land - Tourismusverbände - Wanderwegeersteller (meist Gemeinden) transparenter und nachhaltiger gestalten. Sicher ein Vorteil für die Länder, weniger für die Tourismusverbänden, die den Freiraum gerne nutzen.

Möglicherweise ist auch das Militär daran interessiert. Die eigenen Ressourcen im Institut für Militärisches Geowesen (IMG) reichen für die eigenständige Datenerhebung nicht aus. Die historisch lang zurückreichende Unterstützung durch die Bundesamt für Eich- und Vermessungswesen (BEV) ist 2011 durch Einstellung der Österreichischen Militärkarte weitgehend weggefallen.

Das Hauptproblem bei den Markierten Wegen ist aber die Infrastruktur, die Geodaten des Weges selbst. Die Verortung der Wege war seit 1818 Aufgabe des Militärgeographisches Instituts und seiner Nachfolgerorganisation der BEV. Einsparungsmaßnahmen, Ressourcenknappheit und die vielfältigen Möglichkeiten der Luftaufnahmen reduzierten die Feldbegehungen auf ein Maß, dass die Pflege der kleinen Wegen nicht mehr möglich war. Seit 2014 werden die Wegmarkierungen in den Karten der BEV nicht mehr nachgeführt.

Damit ist auch dem Österreichischen Alpenverein (ÖAV) ein wesentlicher Stützpfeiler weggebrochen. Die AV-Kartographie stellt zwar auch topographische Karten her, aber das sind Hochgebirgskarten, überwiegend in den Ostalpen. Sie sind nicht flächendeckend, bundesweit verfügbar.

ÖAV

Errichtung, Wartung und Dokumentation sind eine Kernkompetenz des ÖAV seit der Gründung 1862 durch drei Studenten in Wien. Die erste AV-Karte wurde bereits 1865 herausgegeben. Heute sind es 56 topographische Hochgebirgskarten der Ostalpen, die laufend aktualisiert werden.

Die markierten Wege in diesen Karten bieten eine hohe Darstellungsqualität bei einfacher Zugänglichkeit. Ganz anders sieht es bei den Wegen außerhalb der Kartenabdeckung aus. Die meist handschriftlichen Skizzen bei den Wegewarten sind von unterschiedlicher Qualität und nur sehr schwer zugänglich.

Seit 2004 arbeiten ÖAV und DAV gemeinsam an der Entwicklung eines alpinen Wege-Informationssystems (WegeGIS). Die beiden Pilot-Projekte EDELWEISS und AWIS (Abschluss 2010) offenbarten den Knackpunkt: woher kommen die Geometriedaten. Weder der ÖAV noch die BEV sahen sich imstande diese Daten flächendeckend zu liefern.

Die Lösung war, die Last auf mehreren Schultern zu verteilen. Die Initialdaten der Wegegeometrien kommen von den Bundesländern. Die Wegewarte der alpinen Vereine attributieren diese Geodaten mit Zusatzinformationen zur Wegeart. Der BEV generiert daraus einen amtlichen Datensatz, der in das Österr. Grundkartenwerk einfließt.

Das Projekt AWIS.GIP ist seit 2016 aktiv. Der ÖAV betreibt eine eigene GIP-Instanz, die mit den Geo-Daten der Projektpartner synchronisiert wird. Die Wegewarte verwenden die benutzerfreundliche App “Contwise Infra” zum Attributieren der Wanderwege. Automatisierte Prozesse synchronisieren die Daten zwischen der Wegedatenbank auf dem Contwise-Server und der AWIS-GIP.

Status Wanderwege in der GIP

Wanderwege im Sinne von Routen über mehrere Wegekategorien gibt es im öffentlich zugänglichen Teil der GIP noch gar nicht. Was es gibt sind einzelne Wegabschnitte die mit “Wanderweg” attributiert sind. Konkret sind das die Tags

Streetcategory 
MW   Mountainbikeweg und Wanderweg 
WA   Wanderweg 

FRC 
300   Wanderweg 

FRC steht für die “Funktionale Straßenbedeutung”. Alle Wege in der GIP danach gefiltert und pro Bundesland zusammenfasst, ergibt (Stand 03/2023):

Bundesland	# Wege	Länge [km]
Vorarlberg	7005	2432,9
Kärnten	3654	989,9
Tirol	3239	944,0
Oberösterreich	2478	626,1
Salzburg	56	28,5
Burgenland	20	5,2
Steiermark	16	3,4
Niederösterreich	0	0,0
Wien	0	0,0

Die nachfolgende Grafik zeigt die regionale Verteilung der Wanderwege und ihre zeitliche Entwicklung von 2019 bis 2023 (Kartenhintergrund (c) OpenStreetmap und Mitwirkende).

Auffallend ist das dichte Wegenetz in Vorarlberg, hier scheint die Erfassung der Wanderwege abgeschlossen zu sein. Demgegenüber fallen die übrigen westlichen Bundesländer bereits deutlich ab. In den östlichen Bundesländern herrscht gähnende Leere.

Bis alle Wanderwege Österreichs in der GIP erfasst sind, werden wohl noch einige Jahre ins Land ziehen.

Ich meine das Dorf Himmelreich in der Gemeinde Raaba-Grambach :-)

Das Hinterland der Industriezentren Raaba und Grambach ist überraschend ruhig und eignet sich hervorragend für Radtouren. Bei einer dieser Touren bemerkte ich den großen Unterschied zwischen der Lage nach Ortstafeln und den geographischen Punkt Himmelreich in der OSM-Karte.

Quelle war das Bundesamt für Eich- und Vermessungswesen (BEV), die das Dorf Himmelreich auf die Höhe von Berndorf verortet, wohingegen alle Ortstafeln deutlich nördlicher liegen:

In obenstehender Grafik stellt die schraffierte Fläche den zusammenhängenden Siedlungsbereich zwischen den Ortstafeln dar. Die Ortschaft selbst ist i.d.R. größer, da Ortstafeln nur den geschlossenen Teil der Ortschaft bezeichnen. Wie weit die Ortschaft Himmelreich reicht ist unklar.

Für Ortschaften gibt es nach Auskunft der Statistik Austria keine offiziellen Polygone. Die Gemeinde ist verpflichtet zu jeder Adresse auch eine zugehörige Ortschaft anzugeben. Aus dieser Punktwolke berechnet die Statistik Austria den Schwerpunkt, der die geografische Lage der Ortschaft angibt.

Leider führt die Gemeinde Raaba-Grambach aktuell keine Ortschaft “Himmelreich” in ihrem Adressregister. Vermutlich wurde mit der Gemeindezusammenlegung auch die Gliederung in Ortschaften geändert.

Historisches

Im Franziszeischen Kataster (1820-1841) gibt es hier keine Ortschaft Himmelreich, es gibt jedoch einen Flurnamen Himmelreich 240m nördlich der Ortslage nach BEV:

Zumindest damals gab es hier noch keine Ortschaft. Im Bereich der heutigen Ortstafeln gab es damals eine Rotte:

Resüme

• die aktuelle Lage der Ortschaft Himmelreich ist unbekannt
• die geographische Lage der Ortschaft nach BEV (und auch OSM) kann ich nicht verifizieren
• die geographische Lage der geschlossenen Ortschaft ist deutlich nördlicher

Die Punktkoordinaten der Ortschaft Himmelreich nach BEV mag einmal zutreffend gewesen sein, sie ist aber mit der heutigen Ausdehnung der geschlossenen Ortschaft Himmelreich nicht mehr in Einklang zu bringen.

Es macht Sinn, die Punktkoordinaten der Ortschaft in die Mitte der geschlossenen Siedlung zu legen. Beispielsweise in die Mitte der Straßenlinie zwischen der südwestlichsten und der nordöstlichsten Ortstafel.

Fersenlutzel und Pudelmutter am Südostrand der Alpen ist eine sehr spannende Sagenlandschaft, unbedingt Wert georeferenziert zu werden, aber in JOSM muss ich es nicht haben. In JOSM landen primär die georeferenzierten Papierkarten mit Rad- oder Wanderwegen, die ich zur Qualitätssicherung meiner Daten verwende.

Nativ unterstützt JOSM keine georeferenzierten Einzelbilder, dazu sind Plugins erforderlich.

Mit JOSM georeferenzieren

Für kleine Bereiche geht das recht gut mit dem Plugin PicLayer [1]. Die optische Vergleichsmethode eignet sich gut für Kartenausschnitte mit wenigen km². Für größere Bereiche wird es zunehmend schwierig. Da ist es besser externe Programme zu verwenden. Welche spielt keine so große Rolle, das Prinzip ist überall ähnlich.

Eine Ausnahme ist das QMapTool Gitterwerkzeug in QMS [2], das ein viel schnelleres Referenzieren von Karten mit Koordinatengittern erlaubt.

Für den problemlosen Austausch der georeferenzierten Bilder sollte man bei einem Koordinaten-Referenzsystem bleiben. Z.B.:

JOSM Default CRS: EPSG:3857 (WGS 84 / Web-Mercator)

GeoTIFF-Bilder in JOSM verwenden

Mit dem GeoTIFF-Format liegt man auf der sicheren Seite. Es gibt kein Format das breiter von GIS-Herstellern unterstützt wird. In JOSM importiert das Plugin ImportImage [4] problemlos alle GeoTIFF-Bilder.

Sollte das Source Reference System unbekannt sein, so kann man raten und viele, viele CRS durchprobieren, bis man das Passende gefunden hat (nach dem Import: Rechtsklick auf TIFF-Layer/Layer Properties/SRS).

Der einzige Nachteil von GeoTIFF ist die Dateigröße. Der Speicherbedarf von großen Scans kann JOSM zum Straucheln bringen. Die LZW-Komprimierung hilft, aber nicht immer genug.

JPG-Bilder in JOSM verwenden

Das Plugin ImportImage unterstützt neben GeoTIFF auch TIFF, JPG, BMP, PNG und GIF. JPG-Bilder haben den Vorteil nur etwa 1/10 der Größe der komprimierten TIFF-Datei aufzuweisen. Diesem Vorteil steht der Nachteil mangelnder Kompatibilität gegenüber. Der Import von georeferenzierten JPG-Bilder scheitert gar nicht so selten. Dazu später mehr.

Das georeferenzierte JPG-Bild besteht aus drei Dateien:

1. <name>.jpg notwendig, Bilddatei
2. <name>.wld notwendig, Geo-Kalibration
3. <name>.prj optional (aber sinnvoll) proj4-Datei

Die World-Datei enthält die Einfügekoordinaten, die Skalierungsfaktoren und die Drehung des Bildes. Statt <name>.wld ist auch <name>.jgw gebräuchlich (analog *.tfw, *.bpw, *.pgw, *.gfw)

Der PRJ-File enthält die Parameter des CRS. Ihn wegzulassen macht nur Sinn, wenn immer derselbe Default-CRS verwendet wird. Fehlt er, wird der CRS von Plugin ImportImage erfragt.

GeoTIFF mit QGIS bauen

Schnell und einfach mit Menü Raster/Projektions/Warp (Reproject):

1. Input Layer auswählen
2. Target CRS = EPSG:3857
3. Advanced Parameters Profile = High Compression
4. Reprojected / Save to File = <FileName>.tif
5. Run

Oder OSGEO4W Shell starten und GDAL Kommando aufgeben:

gdalwarp -t_srs EPSG:3857 -r near -of GTiff -co COMPRESS=DEFLATE -co PREDICTOR=2 -co ZLEVEL=9 <InputFile> <OutputFileName>.tif

Geo-JPG mit QGIS bauen

Der einfachste Weg ist ident zum GeoTIFF, beim Output-File wird nur die Endung in JPG geändert. Leider kann der so erzeugte JPG_File nicht immer vom JOSM Plugin gelesen werden. Datenformat und Transparenzkanal sind Stolperfallen.

Der sichere Weg geht über Translate:

1. QGIS starten und OSM Karte als Layer hinzufügen
2. Referenzierte Karte als Layer hinzufügen
3. Im Menü Raster/Conversion/Translate auswählen
4. Einstellungen: Input Layer = <auswählen> Override the Projection for the output file = EPSG:3857 Additional command-line parameters = -scale –b 1 –b 2 –b 3 Output data type = Byte Converted = <outputFileName>.jpg

Oder OSGEO4W Shell starten und GDAL Kommando aufgeben:

gdal_translate -a_srs EPSG:3857 -ot Byte -of JPEG -scale -b 1 -b 2 -b 3 <InputFile> <OutputFileName>.jpg

WLD-File erstellen

Das JPG-Bild benötigt die Begleitdateien für die Geodaten:

1. Im Menü Raster/Projections/Extract Projection wählen
2. “Create prj-File” anhaken

Alternativ kann beim Bauen der GeoTIFF bzw. Geo-JPG die Creation Option:

• -co “TFW=YES“ (für GeoTiff)
• -co “WORLDFILE=YES” (für JPG u.a.)

hinzugefügt werden.

Geo-PNG mit Mapc2Mapc bauen

In Mapc2Mapc [3] braucht man nichts einstellen, GeoTIFF laden, konvertieren und fertig.

1. Menü File/Load Calibrated Map auswählen
2. Menü File/Write Calibrations auswählen

Es wird das PNG-Bild und ein Satz an Kalibrationsdateien geschrieben. Für JOSM relevant sind die PGW- und TFW-Files. Eine Konvertierung zu JPG ist in Mapc2Mapc nicht möglich, extern geht es natürlich.

Größenvergleich einer Karte mit 5700x5300 px:

Typ	Größe [MB]	Größe [%]
GeoTIFF unkompr.	108 MB	100%
GeoTIFF LZW kompr.	67 MB	62 %
PNG	16 MB	15 %
JPG	7 MB	6 %

Referenzen

[1] JOSM Plugin Piclayer: https://josm.openstreetmap.de/wiki/Help/Plugin/PicLayer

[2} QMapTool in QMS: https://www.naviboard.de/thread/61671-neu-qmaptool/

[3] Mapc2Mapc: https://www.the-thorns.org.uk/mapping/

[4] JOSM Plugin ImportImage: https://wiki.openstreetmap.org/wiki/JOSM/Plugins/ImportImagePlugin

Meine bevorzugte Karte ist die OpenMTBMap. Sie ist mein ständiger Begleiter beim Wandern und Radfahren im Gelände. Ästhetisch ist sie - sagen wir es so - gewöhnungsbedürftig, aber sie informiert hervorragend.

Nur in Städten mag ich sie nicht besonders. Zu viele Details überlagern das Straßenbild bis zur Unkenntlichkeit. Was in freier Natur sinnvoll ist - die Darstellung jeder unterstützender Infrastruktur - ist in Städten kontraproduktiv. Es gibt einfach zu viel davon, die ganze Stadt ist Infrastruktur.

Abb. 1: Prag Altstadt in 3 Karten: Reit- und Wanderkarte[1], OpenMTBMap[2] und Freizeitkarte[3]. Obere Reihe ca. 300 m/cm, untere Reihe ca. 80 m/cm. zoom zoom

Auf der Suche nach Alternativen bin ich bei der Freizeitkarte[3] fündig geworden:

• das Kartenbild wirkt klar und aufgeräumt
• Fuß- und Radwege sind gut sichtbar
• Adresssuche und Routing funktionieren

Am Desktop sind trotz der dezenten Farbgebung der Freizeitkarte die Flächentypen gut unterscheidbar. Beim kontrastarmen Display meines Garmins gelingt das weniger gut. Bei den Flächen stört es mich nicht so, aber die schlechte Erkennbarkeit von Nebenstraßen auf hellen Flächen ist unangenehm.

Abhilfe schafft das Design “contrast”[4] mit intensiveren Farben in den Flächen und verstärkter Straßenkontur.

Abb. 2: Prag Altstadt. Freizeitkarte mit Design “freizeit” (li) und Freizeitkarte mit Design “contrast” (re). Daten: OpenStreetMap and contributors. zoom

Leider nicht ganz: zwar sind die Farben kräftiger, aber nicht alle Straßen sind stärker konturiert. Die Straßen im Altstädter Ring (Bildmitte) sind z.B. weiterhin schlecht sichtbar. Gerade diese verkehrsberuhigten Straßen - Wohnstraßen, Fußgängerzonen und Begegnungszonen - sind mir aber als Tourist wichtig und möchte sie besonders hervorgehoben sehen.

Weitersuchen nach der perfekten Karte? Oh nein, die Freizeitkarte ist ja schon nahezu perfekt für mich und der kleine, fehlende Rest wird sich wohl noch ergänzen lassen. Die Suche und etwas experimentieren führte mich zu den Tools TYPViewer[5] und GMapTool[6]

Tools

Mit GMapTool wird der TYP-File aus der Garmin Karte extrahiert und der editierte Typ-File wieder in die Karte integriert. Mit dem Tool TYPViewer wird der TYP-File editiert und damit das Erscheinungsbild der Karte angepasst.

Das Video von André Biedermann zeigt die Handhabung der Tools.

Meine Anpassungen für Städtereisen

Ein Punkt blieb noch unerwähnt: Kirchen. Kirchen sind ein hervorragendes Orientierungsmerkmal. Warum sie in manchen digitalen Karten gar nicht oder so unauffällig dargestellt werden, ist mir ein Rätsel. Für mich ist es wichtig den Orientierungspunkt Kirchen prominent darzustellen.

Alle Anpassungen:

• POI „Kreuz“ auf 200% skalieren
• Fußgängerzone deutlicher hervorheben
• Wohnstraßen deutlicher hervorheben

Für die Verwendung am Desktop wird ein blasses rosa für die verkehrsamen Straßen verwendet. Ausgangspunkt ist das Design “freizeit.TYP”.

Für die Verwendung am GPS wird ein kräftiges rosa für die verkehrsamen Straßen verwendet. Ausgangspunkt ist das Design “contrast.TYP”.

Die Farbwahl “rosa” ist naheliegend, da die Fußwege in rot dargestellt werden.

Abb. 3: Anpassungen der TYP-Files “freizeit” und “contrast”[4] für Desktop und GPS. Kirchen und verkehrsarme Straßen werden hervorgehoben. zoom

Darstellung am GPS-Gerät

Abb. 3 vergleicht das Erscheinungsbild am GPS-Gerät vom Standard Design “freizeit” mit meinem modifizierten Design. Fußgängerzonen und Kirchen sind deutlich hervorgehoben.

Abb. 3: Fotos vom Garmin Oregon mit 90% Hintergrundbeleuchtung. Links: Karte mit Design “freizeit”. Rechts: Karte mit Design “LeisGPS” (=”contrast” modifiziert). zoom

Karten

Diese Designs eigenen sich nicht nur für die Freizeitkarten[3], sondern auch für die Garmin Leisure Karten vom BBBike Extract Service[7].

Gute Reise!

Referenzen

[1] Nop’s Reit- und Wanderkarte: https://www.wanderreitkarte.de/

[2] OpenMTBMap: https://openmtbmap.org

[3] Freizeitkarte: https://www.freizeitkarte-osm.de/

[4] Freizeitkarte Designs: https://www.freizeitkarte-osm.de/garmin/de/design.html

[5] TYPViewer download: https://sites.google.com/site/sherco40/

[6] GMapTool download: http://www.gmaptool.eu/en/content/windows-setup

[7] BBBike Extract Service: https://extract.bbbike.org/

Es begann mit dem Murradweg R2. In Österreich vorbildlich ausgeschildert und in Tourismusportalen als durchgehend bis Legrad in Kroatien beworben, erlebte ich beim Grenzübertritt zu Slowenien Unerwartetes: es gab keinen Murradweg, der auch als solcher ausgeschildert gewesen wäre.

Dann der EuroVelo 9. In Österreich durchgehend ausgeschildert, endet die Markierung unvermittelt kurz vor Spielfeld, ohne jeden Hinweis auf eine Fortsetzung in Slowenien. Nicht so in OSM: durchgehende Erfassung des EV9 in Slowenien, obwohl es in Slowenien keine EV9-Ausschilderung gibt.

Bei diesen Recherchen bin ich immer wieder auf den Drauradweg gestoßen. Schon beim ersten genaueren Hinsehen, hatte ich das Gefühl, da kann etwas nicht stimmen. Die Vielzahl an Varianten erschien mir unlogisch.

Geschichte des Drauradweges

Der Drauradweg wurde in den 1980er Jahren als Zufahrten zu den Wasserkraftwerksbauten errichtet. Der erste Abschnitt zwischen Spittal und Völkermarkt wurde 1990 als R1 markiert [1].

2002-2006 wurde im Rahmen des EU-Projektes “Drauradweg” eine durchgehende Verbindung vom Toblacher Feld (IT) bis Marburg (SI) errichtet [2].

2007-2013 unterstützte das EU-Projekt “Mura-Drava cycling route” die Weiterführung bis Varaždin und Osijek (HR) [3]. Spätere Programme förderten die laufende Verbesserung der Infrastrukturen.

Wegweisung in Südtirol (IT)

Der Drauradweg wird in Südtirol auf den Pustertal Radweg “3” (Pista ciclabile Val Pusteria “3”) [4] geführt. Auf der Beschilderung hat der Radweg keinerlei Bezeichnung. Es ist nur das allgemeine Symbol für Radroute (percorso ciclabile) angeführt.

Wegweisung in Osttirol (AT)

In Osttirol trifft man zum ersten Mal auf die Bezeichnung Drauradweg R1.

Wegweisung in Kärnten (AT)

In der aktuellen Ausschilderung ist die Routen-Nr. blau unterlegt:

Vereinzelt finden sich auch noch ältere Schilder:

Wegweisung in Slowenien (SI)

Slowenien hat es als einziges Land geschafft, den Drauradweg landesweit einheitlich auszuschildern. Die aktuellen Schilder sind in rot gehalten und der Routenname wird als Symbol dargestellt:

Der touristische Betreiber “drava bike” wird nicht immer genannt.

Vereinzelt sind noch die alten, blauen Schilder, mit weißer Routen-Nr “D-3” anzutreffen. Es gab auch Varianten mit rot unterlegter “3”, “D3” und “D-3”:

Wegweisung in Kroatien (HR)

Die Wegweisung in Kroatien erinnert sehr an Österreich. Die Leitlinie gibt zwar der Staat vor, die Umsetzung und Ausgestaltung obliegt aber den Gespanschaften.

Gespanschaft Varaždin

Im Landkreis Varaždin haben 3 Radrouten die “Drau” im Namen [5]:

R01 National Cycling Route in Varaždin County – Drava – Mura-Drava Cycling Route
R02 National Cycling Route in Varaždin County – Drava – Mura-Drava Cycling Route
R03 National Cycling Route in Varaždin County – Drava Route

Alle drei Routen tragen das “mura-drava”-Logo. mura-drava.bike war ein Interreg-Projekt mit Partnern aus Slowenien und Kroatien zur Entwicklung des Mur- und Drauradweges in diesen Ländern. Das Gemeinschaftsprojekt ist leider gestoppt, die Website www.mura-drava.eu ging 2017 vom Netz.

Gespanschaft Međimurje

Der Tourismusverband hat einen Drauradweg gelistet, die R1 Drava ruta [6]:

Diese Schilder finden sich aber auch an anderen Wegen. Es gibt offenbar mehrere alternative Routen, die gleich ausgeschildert sind.

Auch diese Route führt das “mura-drava”-Logo.

Gespanschaft Koprivničko-Križevačka

Der Tourismusverband hat einen Drauradweg gelistet [7]: Drava Route. Dieser Name findet sich auch auf den Wegweisern:

Es gibt auch Wegweiser mit fast identischen Namen und mit der Routen-Nr “D1”:

Der QR-Code links unten deutet auf ein jüngeres Alter hin. Da beide Schilder nebeneinander vorkommen und in verschiedene Richtungen zeigen, sind es wahrscheinlich zwei unabhängige Routen:

In OSM läuft hier die Relation Drava route. Dem Namen “Drava route” nach müsste die OSM-Route links abbiegen. Tut sie aber nicht, sie geht geradeaus weiter in Richtung der “Drava ruta”. In OSM ist entweder der Name oder der Weg unrichtig.

Gespanschaft Virovitičko-podravsku

Der Tourismusverband hat einen Drauradweg “Drava ruta” [8], in den Teilen West und Ost, gelistet. Die Ausschilderung enthält jedoch einen anderen Namen:

In der Gespanschaft gibt es weitere Drauradwege:

Resüme

Die Ausschilderungen des Drauradweges sind bunt wie eine Frühlingwiese. Die Spur in der Wiese ist in Österreich kaum zu verfehlen, die durchgehende Bezeichnungen mit “R1” und “Drauradweg” sorgen für eine sichere Führung.

Auch in Slowenien gibt es eine durchgehende Beschilderung, die mit dem Drava-Bike-Logo (grün-rotes Fahrrad mit blauer Flusslinie) eine eindeutige Identifizierung erlaubt.

In Kroatien ist die Lage unübersichtlich. DEN Drauradweg scheint es (noch?) nicht zu geben, stattdessen gibt es mehrere lokale Routen, die “Drau” im Namen enthalten. Wie diese lokale Routen zu einem nationalen Drauradweg zu kombinieren sind, wird unterschiedlich gesehen. Die Versionen der Gespanschaften unterscheiden sich z.T. erheblich.

Es macht daher wenig Sinn, eine dieser Varianten in OSM direkt zu mappen. Optimaler ist es, die lokalen Routen möglichst genau zu erfasssen, damit sie - trotz ähnlicher Namen - nicht verwechselt werden können. Eine Zusammenfassung der Teilrouten zur Superroute “Drauradweg” ist ja noch immer möglich.

Eine Erfahrung die ich in Kroatien gemacht habe, ist das Teilen von Routen an Verantwortungsgrenzen, sofern die Ausschilderung nicht 100% ident bleibt. Der Name ändert sich von “Route” zu “Ruta”? - Teilen. Die Routen-Nr fehlt nach der Gemeindegrenze? - Teilen.

Dabei sind Fingerspitzengefühl und lokales Wissen gefragt: eine Beschilderungsänderung durch streckenweise Erneuerung innerhalb der Verantwortungsgrenzen wird anders zu bewerten zu sein.

Bildernachweis

Alle Bilder von Mapillary. Die Ausschnitte wurden intensiv nachbearbeitet.

Referenzen

[1] R. Oberdorfer: Der Drauradweg, Ein Beispiel für nachhaltige Entwicklung im Radtourismus (2015)

[2] Land Kärnten, Abt. 9: Überregionale Radwege in Kärnten (2014)

[3] keep.eu Projects and documents: Mura-Drava cycling route

[4] http://www.bicitalia.org/it/percorsi/100-pista-ciclabile-val-pusteria-da-san-candido-a-rio-in-pusteria

[5] https://bike-routes-vzz.com/biciklisticke-rute/

[6] https://medimurje-bike.com

[7] https://tz-koprivnicko-krizevacka.hr/interaktivne-karte/biciklisticke-staze

[8] https://www.panonske-staze.com/

Die Graphenintegrations-Plattform (GIP) enthält österreichweit eine Vielzahl an Verkehrsinfrastrukturdaten in hoher Detailliertheit. Die GIP beinhaltet Daten für alle Verkehrsformen inkl. Schiffe, U-Bahnen, Seilbahnen, Busse, KFZ, Radfahrer und Fußgänger. Die GIP ist kein fertiges Produkt, sondern wird laufend erweitert. Das betrifft sowohl Inhalt als auch Struktur.

Seit Anfang 2016 werden aktualisierte Datenauszüge der GIP als Open Goverment Data (OGD) in regelmäßigen Abständen veröffentlicht. Das Basisnetz wird in dem einfach zu verwendenden GeoPackage Format angeboten. Der detailreiche Routingexport ist nur im CSV-Format verfügbar.

Der Datenauszug „Routingexport“ ist besonders interessant, da er für das Routing in allen Verkehrsmodi die relevanten Informationen enthält. Unter anderem das routingfähige Netz, die Querschnittselements mit den Erlaubnissen und Verboten nach der StVO u.v.a.m.

Mich interessierten besonders die Daten für Radfahrer. Öfters gibt es Situationen wo die Befahrbarkeit für Radfahrer unklar ist. Beim Abwägen der Merkmale ist die behördliche Sicht natürlich auch ein Argument. Aber nicht mehr, von einer Richtigkeit gehe ich nicht aus.

Ein Blick in die Daten

SynerGIS [2] stellt eine Web-Applikation bereit, die eine kleine Auswahl der Rohdaten mit Raumbezug visualisiert. Der Datenstand wird mit Juli 2018 angegeben. Die Interpretation der Daten ist schwierig, da die Bit-Kodierungen nicht aufgelöst werden. Dennoch, eine nette App für einen ersten Blick auf die Daten.

Einige Länder-GIS [3] präsentieren auch GIP-Daten. Die GIS-Steiermark stellt z.B. bei aktivierten „Fußweg“ Lage und Typ des Nutzungsstreifens für den Langsamverkehr dar. Die Legende gibt dazu näher Auskunft. Bei der Interpretation ist Vorsicht angebracht: Typ des Nutzungsstreifen und Befahrbarkeit werden im GIP immer getrennt modelliert. Eine schmale Begleitstraße (<3 m) wird z.B. im GIP mit Typ 36 „Geh- und Radweg“ bezeichnet. Wer dort fahren darf ist damit nicht gesagt.

Datenimport und Visualisierung

Der Datenimport läuft in zwei Schritten ab: (1) Download der GIP-Daten (gezippte CSV-Files) und (2) Import einer Datenauswahl in ein SQL Spatial Datenbank (Abb 1). Als Frontend wird QGIS verwendet (Abb 2).

Abb 1: Datenfluss Import der Verkehrs-Infrastrukturdaten von GIP.at

Abb 2: Beispiel Visualisierung der GIP-Fahrerlaubnis Radfahrer mit QGIS

Leistungsdaten

Download und entzippen ( 0,5 GB –> 3,5 GB) benötigen ca. 5 min. Der Import von 1,7 GB in die SQL Datenbank (23 Mio Zeilen in 5 Tabellen) ist nach 3 min abgeschlossen. Die Konvertierung der lat/lon-Texte zu räumlichen Daten benötigt noch einmal 2,5 min.

Code

Code und Dokumentation sind auf GitHub verfügbar [4].

Datenqualität GIP vs OSM

Eine valide Bewertung der Datenqualität möchte ich mir nicht anmaßen, aber eine kleine Stichprobe ist sinnvoll, schon allein als vertrauensbildende Maßnahme in die eigene Auswertung. Dazu wurden je 6 Wege mit Fahrverboten für Radfahrer in Wien und Graz gesucht, für die OSM und GIP nicht übereinstimmen.

Die GIP-Fahrerlaubnis für Radfahrer wurde zusätzlich mit dem Routenplaner AnachB überprüft. Anschließend wurde vor Ort verifiziert, wer recht hat. Ergebnisse:

Ort (Anzahl Fälle)	GIP	OSM
Wien (6)	5x richtig	1x richtig
Graz (6)	1x richtig	5x richtig

Nicht uninteressant :-)

Referenzen

[1] GIP.at: Dokumentation Intermodales Verkehrsreferenzsystem Österreich, Datensatz-Beschreibung, http://www.gip.gv.at/#ogd

[2] SynerGIS Wien: Web-Applikation zur Graphenintegrations-Plattform GIP, https://synergis.maps.arcgis.com/apps/webappviewer/index.html?id=1b9896365b5443b1a7dd20d7fe9b70ad

[3] GIS-Steiermark: Digitaler Atlas – Basiskarte – Layer “Verkehr Steiermark” – Fußwege, https://gis.stmk.gv.at/wgportal/atlasmobile/map/Fachkarten/Verkehr

[4] robhubi: Import GIP.at Data (2021), GitHub repository, https://github.com/robhubi/GIPrva

Lange Zeit war mir Mapillary eine wertvolle Unterstützung beim Taggen. Seit einigen Monaten nicht mehr. Mapillary entwickelt sich offenbar in eine Richtung, die meinem - zugegebenermaßen speziellen - Workflow keinen Raum mehr gibt.

Wenn ich draußen unterwegs bin, ist mein Garmin Oregon 650 immer dabei. Videos erstelle ich keine, besondere Situationen halte ich mit Fotos fest. Im Regelfall sind meine Sequenzen kurz: ein Überblicksfoto zur räumlichen Orientierung und einige wenige Detailfotos. Häufige Motive sind Wegweiser, E-Ladestationen, Gebäudedetails u.a.m.

Vor jedem Hochladen prüfe ich die Fotos auf (i) Blickrichtung (ii) die absolute Lage und (iii) die relative Lage zueinander und korrigiere sie gegebenenfalls. Die meisten Fotos benötige ich gar nicht auf Mapillary. Zum Taggen kann ich die Fotos genau so gut in JOSM direkt laden und verwenden.

Nur in Fällen, wo mir das vollständige Taggen zu schwierig oder zu aufwendig ist, füge ich dem Objekt gerne einen Mapillary Link zum Foto hinzu. Das ist der einzige Grund für mich Mapillary zu verwenden und das wurde immer schwieriger. Die Chronologie:

• ab Juli 2020 ist die Blickwinkelkorrektur mit dem Browser sehr umständlich geworden
• zeitgleich begann auch das Zerhacken von zusammengehörigen Bildsequenzen bei Aufnahmen mit Fußgängergeschwindigkeit.
• ab Februar 2021 verschwinden vermehrt hochgeladene Sequenzen. Diese tauchen gar nicht oder erst nach Wochen und Monate wieder auf.
• ab Mai 2021 dauert es oft mehrere Tage bis die hochgeladenen Bilder auf der Karte erscheinen. Wenn überhaupt.
• im Juni 2021 wird der Web-Uploader eliminiert. Der Ersatz - der Desktop Uploader - wird unter Win 10 vom Defender geblockt.

Das ist genug an Hindernissen, um sich nach Alternativen umzuschauen. OpenStreetCam - jetzt Kartaview - bietet sich an. Die Installation lief nicht gerade reibungslos (s.u.), aber von der ersten Erprobung war ich positiv überrascht: die hochgeladenen Bilder bekommen unmittelbar eine ID und können sofort verlinkt werden. Kein Warten mehr, echt cool.

Installation KartaView CLI

Vorausgesetzt wird ein installiertes Python 3.6+. Ich verwende Python 3.7.0 in der OSGeo4w Distribution.

Die KartaView Upload-Scripts können von Github heruntergeladen werden. Das ReadMe ist kurz, so dass einen einfache Installation zu erwarten ist. Leider funktioniert es aber unter Windows 10 nicht. Folgende Schritte führten bei mir zum Ziel:

1. Download “upload-scripts-master.zip” von GitHub
2. Entpacken an einem geeigneten Ort. Z.B.: P:\Kartaview\upload-scripts-master
3. OSGeo4 Shell als Admin starten
4. Eingeben*: py3_env
5. Eingeben: cd /d P:\Kartaview\upload-scripts-master
6. Eingeben: pip3 install virtualenv
7. Eingeben: virtualenv -p python3 .
8. Eingeben: scripts\activate.bat
9. Eingeben: pip3 install -r requirements.txt
10. fertig

Schritt 4 setzt die Path-Variable auf Python. Erst danach liefert z.B. python --version eine korrekte Antwort.

Schritt 7 ergab zunächst eine Fehlermeldung: “FileNotFoundError: [Errno 2] No such file or directory: ‘…\osgeo4w64\bin\pythonw.exe’ “. Abhilfe: in diesem Verzeichnis pythonw3.exe kopieren und als pythonw.exe wieder einfügen

Upload Fotos mit KartaView CLI

1. OSGeo4 Shell als Admin starten
2. Eingeben*: py3_env
3. Eingeben: cd /d P:\Kartaview\upload-scripts-master
4. Eingeben: scripts\activate.bat
5. Eingeben: python osc_tools.py upload -p G:\Bilder\OSC
6. fertig

Schritt 5 lädt die Bilder hoch, die sich im Verzeichnis “…\OSC” befinden. Für mehrere Sequenzen, sollte pro Sequenz ein eigenes Unterverzeichnis unterhalb von OSC angelegt werden. Mehr Details in [2].

Upload Fotos mit einem Klick

1. OSCuploadMaster.bat als Admin starten
2. fertig

Alle Befehlszeilen können in zwei Batch-Files zusammengefasst werden:

Batch-File OSCuploadMaster.bat:

call  P:\OSGeo4W64\OSGeo4W.bat start cmd.exe /k P:\OSGeo4W64\bin\myScripts\OSCupload.bat

Batch-File OSCupload.bat:

call py3_env.bat
cd /d P:\Kartaview\upload-scripts-master
call scripts\activate.bat
python osc_tools.py upload -p G:\Bilder\OSC
Pause

Referenzen

[1] GitHub: Uploader Tools for KartView, https://github.com/kartaview/upload-scripts

[2] Blog von mvexel: Using the new OpenStreetCam upload scripts, https://www.openstreetmap.org/user/mvexel/diary/47898

*Update 19. Dez. 2021, Python 3.9.5

Nach dem Update von Python 3.7.0 auf 3.9.5 waren die Upload-Skripte gebrochen. Auch ein Neuaufbau der virtuellen Umgebung war zunächst nicht möglich. Es gab zwei Fehlermeldungen:

1. im Schritt 4: “py3_env … not found”
2. im Schritt 9: “pip is configured with locations that require TLS/SSL, however the ssl module in Python is not available”

Der erste Fehler war leicht zu beheben: “py3_env” einfach weglassen, in der aktuellen Python-Version ist es nicht mehr notwendig.

Der zweite Fehler wurde mit der Installation des “OpenSSL-Toolkits v1.1.1m Light” behoben. Download Win64OpenSSL_Light-1_1_1m.exe von https://slproweb.com/products/Win32OpenSSL.html

Die reine Lehre ist da eindeutig: der Grundriss soll dargestellt werden. Gut, was aber, wenn (a) der Grundriss nicht sichtbar und (b) er völlig anders aussieht, als die Umrisse im Luftbild? Welche Darstellung bringt mehr Vorteile?

Der betreffende Gebäudekomplex hat funktionell 2 Ebenen: die Geschäftsebene besteht aus einem großen Parkplatz, einem Supermarkt und weiteren Geschäften. Diese Ebene bildet das Erdgeschoß und ist vollständig überdacht. Die zweite Ebene - die Wohnebene - besteht aus vier Wohngebäuden, die auf der Überdachung gründen.

Zu dem Zeitpunkt waren in OSM die Wohngebäuden aus dem Luftbild gemappt. Für die Orientierung im Gelände war dieser markante Umriss sicher vorteilhaft. Andererseits, ist nicht die Lage eines Parkplatzes zu einem Supermarkt von noch größerem Interesse?

Abb1: Bauphase Projekt “City Gate” im Luftbild (li) und in OSM (re)

Ich meine ja und habe mich daher entschlossen, das bestehende Mapping abzureißen und neu aufzubauen. Doch halt, abreißen ist nicht gerade die feine, englische Art, also besser umbauen. Die Idee: Grundriss wie üblich in 2D darstellen und bestehende Wohngebäude in 3D überführen.

Abb 2: Restrukturierung in OSM. Grundriss in 2D (Level 0), Gartendeck und Wohngeschoße in 3D (Level 1 bis Level 15). (c) OpenLevelUp! und (c) OpenStreetMap Contributors

Mapping 2D

Die Gebäudeteile im EG sind über eine Multipolygon Relation zusammengefasst. Prinzipiell ist das nicht notwendig, aber es erleichtert die Selektion, da doch sehr viele 3D-Linien darüberliegen.

Linien	Tags
	Relation — type=multipolygon — landuse=residential Mitglieder outer — (ohne Tags) inner — building=yes — height=3.5 — level=0

Mapping 3D

Die 3D-Gebäude sind in einer Building Relation zusammengefasst. Die Rolle outline fehlt per Design, da der Grundriss unabhängig davon modelliert wurde.

Linien	Tags
	Relation — type=building Mitglieder mit Rolle part — building:part=yes — height=… — min_height=… — building_levels=… — building:min_level=…

Darstellung in Karten

Bei diesem Design ist die Grundrissdarstellung vollkommen unabhängig von der darüberliegenden 3D-Struktur. Das störungsfreies 2D Rendering war daher zu erwarten. Die 3D-Struktur ist durch das fehlende outline-Mitglied eine wenig ungewöhnlich. Die meisten der getesteten 3D Renderer kommen aber damit zurecht:

Kendzi 3D - ok
OSM Buildings - ok
3Dbuildings - ok
OSMgo25 - fast ok, Stiegenhaus 165 fehlt
F4map - ok

Resümee

Die in der Realität vorhandene, deutliche Trennung der Geschäftsebene von den darüberliegenden Wohnebenen lässt sich gut in den OSM 2D- bzw. 3D-Datenstrukturen spiegeln.

Edit 16. Jän. 2021: F4map rendert nun alle Gebäudeteile, ohne dass die Datenstruktur geändert wurde.

Im Frühjahr ist mir im Burgenland eine neu ausgeschilderte Radroute aufgefallen, der EuroVelo 14 “Waters of Central Europe Route”. Daraufhin habe ich die Relationsstrukturen des EV14 in OSM angelegt und die bestehende Teile in Ungarn und den neuen Teil im Burgenland eingefügt. Die Teile in Salzburg und der Steiermark blieben leer, da sie nicht ausgeschildert waren.

Wenig überraschend dauerte es nicht lange und die Lücken waren geschlossen. Meine Frage an den Mapper, welche Quelle er benutzte, beantwortete er mit entwaffnender Offenheit:

… The GPX of the EuroVelo routes can be downloaded publicly from the EuroVelo website (https://www.eurovelo.at/en) … I have no ‘ground’ knowledge of the EV14. My only goal is to have the route mapped completely such that cyclists from all over the world can enjoy it, which is the goal of the European Cyclists’ Federation. …

So sympathisch die Motive sind, so gibt es doch einige Problempunkte, die ich exemplarisch an diesem Fall ansprechen möchte.

Tags

Die Relation route=bicycle beschreibt ausschließlich ausgeschilderte Routen [1]. EuroVelo-Abschnitte, die nicht ausgeschildert sind und auch keiner anderen Rad-Relation angehören, haben keine Grundlage um in OSM erfasst zu werden.

Qualität

Verifizierte Fakten sind das Qualitätsmerkmal von OSM. Für Tourenportale ist anderes wichtiger. EuroVelo ist da keine Ausnahme, wie die Gegenüberstellung des EV14-Burgenlands zeigt:

Abb 1: Zwei Tracks des EuroVelo 14 in Burgenland. “rot” - runtergeladene Route vom EuroVelo-Portal [2]; “grün” - ausgeschilderte Route in OSM [3] (Kartenbild: OpenStreetMap und Mitwirkende)

Die Originalroute „ECF“, vom EuroVelo Portal heruntergeladen, weicht erheblich von der ausgeschilderten Route „OSM“ ab.

Urheberrecht Reiseverlage

Ein automatisiert erstellter GPS-Track für sich allein ist ziemlich sicher nicht geschützt, da Schöpfungshöhe und Individualität eher gering sind. Als Teil eines Werkes “Reisebeschreibung” kann es aber sehr wohl geschützt sein. Eindeutig ist es natürlich, wenn die Web-Seite die Nutzungsbedingungen explizit anführt.

• Der Verlag Esterbauer schreibt dazu [4]:
  The tracks and data, which you can download here for private use, supplement the products of the publisher Esterbauer and are protected by copyright. The transfer and distribution of this data to third parties is therefore not permitted.

• Die Seite Informaçãos Turística, Lucete Fortes schreibt dazu [5]:
  Die GPS-Tracks sind Copyright geschützt, genauso wie die Texte, Fotos, Klassifizierung und Nummerierung der Wege in unseren Büchern und Karten! Also … liebe Hobbykartographen: Statt bleichgesichtig nächtens über dem Bildschirm zu hängen und zu klauen - genießt selbst die Natur und zeichnet eure eigenen Tracks auf! Qualität beginnt mit dem Vor-Ort-Prinzip und macht Freude!

Das sitzt ;-)

Urheberrecht EuroVelo

EuroVelo Austria schreibt [6]:

• Die Weiterverbreitung ist erlaubt, sofern die Quelle bestätigt werden kann und nichts anderes angegeben wurde. Im Falle vorher einzuholender Erlaubnis für die Verbreitung textueller und multimedialer (Audio, Bilder, Software etc.) Informationen ist die allgemeine Erlaubnis nichtig und muss gegebene Einschränkungen der Nutzung angeben.

Wegen der unbestimmten Quellenlage hätte man das mit “Alle Rechte vorbehalten” auch einfacher formulieren können. Der englische Originaltext findet sich übrigens bei ECF [7]

EuroVelo International wird konkreter:

• Reproduction of the text is generally authorized, provided the source is acknowledged, except where otherwise stated. [8]
• Unless explicitly stated otherwise, we license all the content of our website under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License [9]

Diese Lizenz ist mit OSM inkompatibel. Der GPS-Track wäre nur mit einer expliziten Erlaubnis für OSM nutzbar.

Resümee

Bitte verwendet keine Tracks von Portalen, außer ihr seid euch beim Urheberrecht und bei der Qualität ganz sicher.

Referenzen

[1] OSM Wiki Tag:route=bicycle
[2] EuroVelo EV14 Track GPX, abgerufen am 29.Okt.2020
[3] OSM EV14, Teil Burgenland, abgerufen am 29.Okt.2020
[4] https://www.esterbauer.com/gps.html
[5] https://www.bela-vista.net/Santo-Antao-GPS.aspx
[6] https://www.eurovelo.at/en/imprint
[7] Copyright notice in: https://ecf.com/legal-statement
[8] https://en.eurovelo.com/terms-and-conditions
[9] In Fußzeile von: https://ecf.com/legal-statement

Die Unterscheidung fällt nicht immer leicht, da die Gehsteige (Bürgersteige, Trottoirs) selbst schon sehr unterschiedlich gestaltet sein können. Einige Beispiele zu Gehsteigformen wurden im AT-Forum kürzlich diskutiert.

Die Unterscheidung Gehsteig oder Begleitweg ist insbesondere für Radler und Mapper von Bedeutung, da Radeln:

• am Gehsteig prinzipiell verboten ist
• am Begleitweg prinzipiell erlaubt ist

Verkehrsschilder wie “Radweg”, “Gehweg” oder “Geh- und Radweg”, sofern sie vorhanden sind, klären natürlich die Sachlage. Um die anderen Fälle geht es hier.

Begriffe

Relevante Begriffe laut Straßenverkehrsordnung:

Gehsteig: ein für den Fußgängerverkehr bestimmter, von der Fahrbahn durch Randsteine, Bodenmarkierungen oder dgl. abgegrenzter Teil der Straße; [1] Abs. 1 Z 10

Straße: eine für den Fußgänger- oder Fahrzeugverkehr bestimmte Landfläche samt den in ihrem Zuge befindlichen und diesem Verkehr dienenden baulichen Anlagen; [1] Abs. 1 Z 1

Begleitwege sind in der StVO nicht definiert. Im üblichen Sprachgebrauch sind es eigenständige Wege, gleichlaufend zu höherrangingen Straßen, Bahntrassen, Dämmen und dgl.

Abgrenzung Gehsteig zu Begleitweg

Die Kriterien leiten sich aus den Definitionen ab: Gehsteig = Teil der Straße; Begleitweg = Nicht-Teil der Straße. Der entscheidende Punkt ist: wo ist der äußerste Straßenrand? Einen Hinweis gibt [2] Abs. 3 durch die Festlegung von Mindestabständen zu Straßenrändern.

Abb 1: Eingebettete Straße. Der Straßenrand ist das äußerste Ende der Frostschutzschicht. Daumenwert für den Fahrbahnüberstand: 2x Bankett oder - falls das Bankett begrünt ist - 20% der Fahrbahnbreite (Quelle)

Abb 2: Aufgedämmte Straße. Der Straßenrand ist der Böschungsfuß bzw. der äußere Rand des Grabens (Quelle)

Abb 3: Eingeschnittene Straße. Der Straßenrand ist der Fuß der Dammböschung bzw. die oberen Kante der Einschnittböschung (Quelle)

Abb 4: Allee. Alleebäume sind seit alters her Teil der Straße. Aus [3]

Resümee

Nachdem nun der Blick geschärft ist, was zeigt das Titelbild [4]: Gehsteig oder Begleitweg?

:-)

Referenzen

[1] § 2 StVO 1960 Begriffsbestimmungen; https://www.jusline.at/gesetz/stvo/paragraf/2

[2] § 49 T-StG Bauliche Anlagen an Straßen; https://www.jusline.at/gesetz/t-stg/paragraf/49

[3] O. Hübner: Der Straßenbaum in der Stadt und auf dem Lande, seine Pflanzung und Pflege, sowie die erforderlichen Maßnahmen zu seinem Schutz, Berlin 1914; Link

[4] Mapillary

Der Weißenegger Mühlgang. ursprünglich ein Nebenarm der Mur, treibt seit mehr als 500 Jahren mehrere Mühlen und heute auch Elektrizitätswerke an. Seit Jahrhunderten heißt der Wasserlauf Weißenegger Mühlgang (Abb 1), in OSM wird er jedoch Weissenegger Mühlkanal genannt. Woher kommt das?

Abb 1: Weißenegger Mühlgang in einer Karte von 1757 (li) und in OpenStreetMap (re, Schriftzug “Weissenegger Mühlkanal” vergrößert). Quellen: Mapillary; OpenStreetMap-Mitwirkende

Die Frage stellt sich, da Mühlgang und Mühlkanal nicht einfach Synonyme sind. In Südösterreich ist ein Mühlgang ein ursprünglich natürlicher, nunmehr meist regulierter Wasserlauf. Kanal hingegen ist ein vollständig künstliches Wasserbauwerk. Mühlkanal klingt befremdlich und ist hier unüblich.

Status OSM

In OSM [1] weist die Chronik das Erstelldatum des Weissenegger Mühlkanals mit 20.09.2011 aus. Als Quelle ist “plan.at 2009” angegeben. Der Name ist seit damals unverändert geblieben. Er ist über die gesamte Länge, bis zur Einmündung in die Stiefing, als waterway=canal getaggt. Das ist weitgehend unrichtig, nur der im Zuge des Kraftwerksbaues Mellach neu errichteter Einfang könnte auf einer Strecke von 690 m als Kanal bezeichnet werden. Der große Rest ist überwiegend natürlichen Ursprunges und wäre mit waterway=river passender getaggt.

Status vor Ort

Eine Anfrage [2] bei der Gemeinde Wildon nach der ortsüblichen Bezeichnung des Wasserlaufes wurde mit “Weißenegger Mühlgang” beantwortet. Die Bezeichnung Mühlkanal ist nicht geläufig.

Eine Infotafel bei Wildon benennt den Wasserlauf ebenfalls mit Weißenenegger Mühlgang (Quelle: Mapillary):

Status offizielle Karten

In der Verwaltungsgrundkarte Österreichs basemap.at wird das Gewässer Weissenegger Mühlkanal genannt. Ebenso in der Digitalen Gewässerkartei Steiermark [3].

Offensichtlich folgt OSM hier der offiziellen Linie und und ignoriert die ortsübliche Bezeichnung. Zu dem Zeitpunkt war ich mir unsicher, wer in OSM mehr Gewicht zukommen soll: Verwaltung oder Ortsansässige. Oder ist der Verwaltung ein Fehler unterlaufen? Hmm - also weiter recherchieren.

Regionale Häufigkeit Mühlgang und Mühlkanal

Mit einer Overpass Query kann sehr einfach die Häufigkeit von geographischen Namen ermittelt werden. Die Abfrage auf Mühlgang bzw. Mühlkanal ergibt folgende Verteilung:

Tab 1: Geographische Verteilung der Namen “Mühlgang” und “Mühlkanal” in der Steiermark, Österreich und Deutschland (nwr = Anzahl Nodes / Anzahl Ways / Anzahl Relations) . Quellen: Overpass Turbo; OpenStreetMap-Mitwirkende

	Mühlgang	Mühlkanal
Steiermark	nwr= 4057/366/5	nwr= 406/14/0
Österreich	nwr= 4136/378/5	nwr= 483/24/0
Deutschland	nwr= 11/1/0	nwr= 5884/708/5
Schweiz	nwr= 0/0/0	nwr= 0/0/0

Von wenigen Ausnahmen abgesehen: die Bezeichnungen “Mühlgang” gibt es nur in Südösterreich und “Mühlkanal” nur in Süddeutschland.

Zeitleiste Häufigkeit Mühlgang und Mühlkanal

ANNO [4] ist das historische Archiv der österreichischen Nationalbibliothek. Es können mehrere Millionen Zeitungsseiten, aus dem Zeitraum 1689-1949 online gelesen und durchsucht werden. Die Abfrage ist denkbar einfach, die Ergebnisse schwanken jedoch ein wenig bei Wiederholung der Abfrage. Das Lesen der Fraktur-Schrift scheint nicht immer dasselbe Ergebnis zu liefern [5]. Für die prinzipielle Aussage ist das jedoch ohne Bedeutung.

Abb1: Anzahl der Nennungen “Mühlgang” bzw. “Mühlkanal” in historischen Zeitungen und Zeitschriften der Österr. Nationalbibliothek ab 1775 (Quellen: Daten von ANNO/Österreichische Nationalbibliothek, eigene Darstellung)

Mühlgang wird im ANNO-Archiv zum ersten Mal 1788 in der Wiener Zeitung erwähnt. Erst 37 Jahre später wird Mühlkanal im Feldkircher Wochenblatt vom 23. August 1829, zum ersten Mal erwähnt. Ein deutlicher Hinweis für den deutschen Ursprung.

Auffällig ist die Häufung in den Jahren 1900-1924, mit einem absoluten Maximum im Jahre 1913. Der Mühlgang wird häufig im Kontext von suizidalen Vorfällen erwähnt. Hier spiegelt sich der Zusammenbruch der Welt. Meldung des Grazer Tagblatts, Di, 9. September 1913:

Heute vor 7 Uhr früh sprang das 15 Jahre alte Schneiderlehrmädchen Marie Rezabek in der Mühlgasse in den Mühlgang. Es gelang dem Geschäftsdiener Josef Feichter, sie zu retten …

Das in Abb 1 dargestellte Verhältnis Mühlgang zu Mühlkanal blieb in Österreich über die Jahrhunderte ziemlich konstant. Üblich war immer die Bezeichnung Mühlgang.

Historische Grundbücher

Grundbücher sind ein chronologisches Verzeichnis von Besitzer, Rechten, Pflichten und topografischen Lagen von Grundstücken. Im steirischen Landesarchiv können diese eingesehen werden. Dem Weißenegger Mühlgang ist zumeist die Einlagezahl 50001 zugeordnet. Diese Nummer führt ins Leere, sie besagt, dass es sich um ein öffentliches Gut handelt und keine weitere Information existiert.

Katasterpläne

Das Katasterarchiv der BEV - Bundesanstalt für Eich- und Vermessungswesen - dokumentiert seit 1880 jede Veränderung im Kataster. Der Maßstabsbereich von 1:250 bis 1:5000 ist genau genug, um die Gewässernamen zu finden. Beispiele:

K.G. Mellach, G.Z. 9729 vom 10. Aug. 1981, Dipl. Ing. A. Legat: “Weißenegger Mühlkanal” K.G. Mellach, G.Z. 11080 vom 10. Nov. 1983, Dipl. Ing. A. Legat: “Mühlgang”

Die Gewässernamen sind offenbar in den Katasterplänen nicht stabil. Ein Mitarbeiter der BEV [6] kommentierte diese Variabilität mit den Worten:

Gewässernamen sind nicht verbindlich, nur informativ. Vergleichbar mit Vulgo-Namen und Ried-Bezeichnungen.

Österreichische Karte 1:50000

Die ÖK50 und die Vergrößerung ÖK25V ist das topographische Grundkartenwerk Österreichs. Die historischen Ausgaben wären für die Veränderungen der Namen eine großartige Quelle. Leider ist nur die aktuelle Ausgabe online verfügbar. Daher habe ich eine offizielle Anfrage an die BEV gerichtet: “Wann und warum der “Weißenegger Mühlgang” in den “Weissenegger Mühlkanal” umbenannt wurde. Antwort [7]:

Der „Weißenegger Mühlkanal“ (bzw. Mühlgang) wurde ab der 3. Landesaufnahme (um 1870, 1:25 000 Präzisionsaufnahme der k.u.k. Monarchie) an dieser Stelle nicht beschriftet, später in der Spezialkarte 1:75 000 bzw. provisorischen Ausgabe 1:50 000 auch nicht, erst ab der Photogrammetrischen Neuaufnahme nach dem 2. WK (ÖK50 BMN) wieder beschriftet, dann allerdings eben immer als „Mühlkanal“.

Also wurde hier „Mühlgang“ vor 1870 verwendet. Allerdings wurde und wird und wurde die schöne Bezeichnung „Mühlgang“ an anderen steirischen Gewässern noch immer verwendet, sowohl früher in der 3. LA als auch heute im KM50 (z.B. südöstlich von Lebring..) Es stimmt, dass das KM50 hier nicht ganz konsistent ist.

Im Allgemeinen wurden die Namen einerseits vom Topographen vor Ort erhoben, gelegentlich auch von einer Nomenklaturkommision geprüft.

Wir werden ihre Anregung zum Anlass nehmen, ihren Hinweis an die Abt. Landschaftsinformation weiterzuleiten zur Prüfung und möglichen Änderung in KM50.

Weitere Mühlkanäle

Fernitzer Mühlkanal

Der Fernitzer Mühlgang ist historisch gut belegt, in ANNO sind 15 Erwähnungen, im Zeitraum von 1889 bis 1929, abfragbar. Zum Fernitzer Mühlkanal gibt es in ANNO genau 0 Treffer. In der ÖK50-Karte der BEV, Blatt 190/2 Stand 1950/53, heißt das Gewässer noch Mühlkanal:

Abb2: Fernitzer Mühlgang in ÖK50 von 1953 (li) und Fernitzer Mühlkanal in aktueller Gewässerkarte. Quellen: (C) BEV 2020 (li) und (c) GIS-Steiermark (re)

Ortüblich ist die Bezeichnung Mühlgang.

Gössendorfer Mühlkanal

Über den Gössendorfer Mühlgang ist nur wenig historisches Material zu finden. So liefert ANNO für den Gössendorfer Mühlgang nur 1 Treffer und für Gössendorfer Mühlkanal genau 0 Treffer. Eine hervorragende Quelle mit vielen Detailinformationen ist [8]. Auf Seite 36 ist u.a. der Verlauf des Gössendorfer Mühlganges dargestellt.

Ortüblich ist die Bezeichnung Mühlgang.

Mühlkanal bei Laufnitzdorf

Der Bau wurde 1929 begonnen und 1932 fertiggestellt. Die Bezeichnung “Kanal” ist hier korrekt, da es sich um ein vollständig künstliches Wasserbauwerk handelt. Der Oberwasserkanal führt das Triebwasser für das Verbund-Kraftwerk Laufnitzdorf.

Die Benennung Mühlkanal ist skurril, da es ja explizit für ein Kraftwerk gebaut wurde und nie eine Mühle versorgte.

Zusammenfassung

Benennungen mit Mühlgang sind seit mehr als 600 Jahren in Südösterreich gebräuchlich. Auch heute noch ist diese Bezeichnung im täglichen Wortschatz zu finden. Es ist nicht nachvollziehbar warum die BEV in Einzelfällen eine Umbenennung in Mühlkanal vorgenommen hat.

Viele Gewässer haben in Österreich gar keinen Namen. Wenn sie einen Namen haben, scheint der offizielle Prozess der Namenserhebung wenig kontrolliert zu sein. Varianten in der Benennung können vorkommen und haben keine besondere Konsequenzen, da die Namen - ähnlich wie Vulgonamen - nur informativen Charakter haben.

Damit neigt sich die Waagschale, eine ortsübliche Bezeichnung, die über Jahrhunderte konstant in Gebrauch ist, hat für mich mehr Gewicht, als eine aktuelle amtliche Bezeichnung, die zur Variabilität neigt.

Ich werde in OSM die Mühlkanäle bei Weißenegg, Gössendorf und Fernitz in Mühlgänge rückbenennen.

Referenzen

[1] https://www.openstreetmap.org/way/130669739/history
[2] Mail vom 19. Juni 2020 *@wildon.gv.at, Betreff: “Wildon, Weißenegger Mühlgang ist richtig”
[3] Digitaler Atlas Steiermark Gewässer & Wasserinformation: https://www.landesentwicklung.steiermark.at/cms/ziel/141979637/DE/
[4] ANNO - AustriaN Newspapers Online, http://anno.onb.ac.at/
[5] Persönliche Mitteilung von Ingo Mirsch, per Mail am 23. Juni 2020
[6] Mündliche Mitteilung vom Kundenservice der BEV Graz, 02. Juli 2020
[7] Mitteilung TSK-00075080 vom BEV Kundenservice per Mail am 07. Juli 2020
[8] Bodner Werna, Galli Johanna: Zeichen setzen - Von der Mühle zur Werkstatt, Diplomarbeit TU-Graz (2014), https://diglib.tugraz.at/zeichen-setzen-2014

Ein freundlicher Gastwirt schickte mir einen Kartenauszug mit den von ihm 1992 ausgeschilderten Radwegen. 28 Jahre sind eine lange Zeit, ob die Route auch heute noch “scenic” ist?

Leider war die Fotokopie so schlecht, dass ein Georeferenzieren über Landmarken mühselig zu werden drohte. Aussichtsreicher erschien der Weg über das Koordinatengitter.

Abb 1: Radrouten um Laßnitzhöhe (1992). Quelle: [1]

Das Kartenbild enthielt ein Koordinatengitter, die Beschriftungen waren jedoch außerhalb des Auszuges. Durch Vergleich mit einer ÖK25-V Karte war jedoch bald klar, das ist ein Bundesmeldenetz in Gauß-Krüger Projektion.

Doch wie zu den Koordinaten kommen? Das System ist schon so lange nicht mehr in Verwendung, dass die Online-Recherchen nur mehr spärliche Informationen liefern. Die Mosaiksteinchen zusammengesetzt ergeben folgendes Bild:

Abb 2: Ausschnitt der Österreichischen Karte 1:25 000, Blatt BMN 6707, Graz. Das „X“ repräsentiert den Messort mit den abgelesenen Koordinaten: Rechtswert y = 676 000 und Hochwert x = 210 000 (Quelle: Wikimedia Commons)

BMN GK-Koordinaten ablesen

Das Bundesmeldenetz (BMN) dient der vereinfachten Ortsangabe. Vorteilhaft sind die kleinen Zahlen und der Entfall des Bezugsmeridians. Die BMN-Werte in Gauß-Krüger Abbildung (GK) können einfach aus der Karte berechnet werden: Kleine und große Ziffern aus der Karte zusammennehmen und mit 1000 multiplizieren.

Beispiel für den Ort „X“ in Abb 2:

X(y_BMN_GK, x_BMN_GK): 676 000, 210 000

Eine einfache Transformation stellt den Zusammenhang zwischen BMN GK-Koordinaten und den GK-Koordinaten her [2]. Genau diese Transformationsparameter müssen im EPSG-Code enthalten sein.

Hochwert: x_BMN_GK = x_GK – 5 000 000
Rechtswert M28: y_BMN_GK = y_GK + 150 000
Rechtswert M31: y_BMN_GK = y_GK + 450 000
Rechtswert M34: y_BMN_GK = y_GK + 750 000

Die genaue Lage der Katastralgemeinden zu den Bezugsmeridianen ist in [3], S15ff dokumentiert.

Beschreibung der Koordinaten mit EPSG-Codes

Den passenden EPSG-Code [4] zu finden ist nicht ganz einfach. Der Name gibt nur einen groben Anhaltspunkt. Auf die Parameter schauen oder durchprobieren. Für die BMN GK-Koordinaten in M34 passt

EPSG:31259 - MGI/Austria GK M34

Mit dem proj.4-Code [5]:

+proj=tmerc +lat_0=0 +lon_0=16.33333333333333 +k=1 +x_0=750000 +y_0=-5000000 +ellps=bessel +towgs84=577.326,90.129,463.919,5.137,1.474,5.297,2.4232 +units=m +no_defs

Alle EPSG-Codes für das BMN in GK

EPSG:31257 - MGI/Austria GK M28
EPSG:31258 - MGI/Austria GK M31
EPSG:31259 - MGI/Austria GK M34

Georeferenzieren

Mit dem Gitterwerkzeug in QMap Tool und der Kenntnis des richtigen EPSG-Codes (+init=epsg:31259) war es in wenigen Minuten erledigt. Der maximale Ortsfehler lag bei 100m, das war ausreichend für eine eindeutige Identifizierung der markierten Wege.

Abb 3: Georeferenzierte Fotokopie mit transparent überlagerter Landkarte. (Quellen: Kartendaten: (c) OpenStreetMap - Mitwirkende; Rendering: (c) OpenTopoMap; Fotokopie: [1])

Tour

Überwiegend sehr schöne Streckenführung. Beschilderung nur mehr in Resten vorhanden.

Referenzen

[1] Fam. Csaszar, persönliche Mitteilung, 30.03.2020

[2] BEV, Koordinatensysteme
http://www.bev.gv.at/pls/portal/docs/PAGE/BEV_PORTAL_CONTENT_ALLGEMEIN/0200_PRODUKTE/PDF/KOORD-SYS.PDF

[3] BEV, 3-D Referenzsysteme in Österreich
https://www.bev.gv.at/pls/portal/docs/PAGE/BEV_PORTAL_CONTENT_ALLGEMEIN/0200_PRODUKTE/SCHNITTSTELLENBESCHREIBUNGEN/SYSTEME_LANDESVERMESSUNG_2015.PDF

[4] BEV, EPSG-Übersicht: Geodätisches Datum und Projektionen in Österreich
http://www.bev.gv.at/pls/portal/docs/PAGE/BEV_PORTAL_CONTENT_ALLGEMEIN/0100_NEWS/ARCHIV_2007/NEUE%20EPSG%20-%20CODES%20FUER%20OESTERREICH/PROJEKTIONEN_TRANSF.PDF

[5] Spatial Reference
https://spatialreference.org/ref/epsg/31259/

1 Zusammenfassung

DIE Wahrheit ist natürlich eine schöne Illusion. Aber der Wahrheit näher kommen, sie auf ein bestimmtes Maß einzugrenzen, das ist machbar. Der Weg führt über Fehleranalysen und experimentell unterstützte Abschätzungen zu einem einfachen Modell für die Berechnung des kumulierten Anstieges. Am Ende steht die Antwort, welches Tool am besten rechnet.

Methodenwahl Soll die Höhe mit GPS oder barometrisch bestimmt werden? Die GPS-Höhenmessung streut sehr stark (1sa = mehrere Meter) und neigt bei Abschattungen zu Ausreißern. Die barometrische Höhenmessung streut in kurzen Zeitperioden sehr wenig (1sa = mehrere cm), geht jedoch langfristig mit dem Wetter mit.

Im Normalfall – flache Teilstücke wechseln sich mit steileren Abschnitten ab – ist die niedrige Streuung der barometrischen Höhenmessung für die Berechnung des kumulierten Anstiegs eindeutig vorteilhaft.

Sensorrauschen Aktuelle Drucksensoren für Höhenmessungen haben ein ungemein niedriges Rauschen von <2cm. Diese phantastische Entwicklung kommt vom breiten Einsatz in Smartphones und der Hoffnung auf Indoor Navigation.

Druckrauschen Es gibt kein stabiles Wetter. Die 50 km hohe Luftsäule, die auf den Sensor drückt, wabert die ganze Zeit hin und her und erzeugt damit Druckschwankungen. Das Druckrauschen kann mit 2 nahe beieinanderliegenden Messstationen abgeschätzt werden. Die beiden LUIS-Stationen in Graz-Nord und Oeversee Park hatten im Wochenschnitt (1/2h Auflösung) eine Streuung von 1sa = ±0,125 hPa. Das entspricht einem Höhenrauschen pro Station von 1sa = ±0,75 m.

Sonstige Einflussgrößen Absolute Richtigkeit und Winddruck sind in erster Näherung vernachlässigbar. Nur die Sensor-Temperatur könnte sich noch bemerkbar machen. Der Sensor BMP280 ist z.B. mit ±12,6 cm/K spezifiziert. Für genaue Höhenmessungen sollten längere Pausen in der Sonne vermieden werden.

Experimentelle Bestimmung der Messunsicherheit Das ist ganz einfach. Denselben –vorzugsweise flachen – Rundkurs 21 mal fahren und die Höhen mit dem Baro korrigieren. Der Mittelwert der Höhen ist eine gute Schätzung für das wahre Höhenprofil. Die durchschnittliche Abweichung vom Mittelwert ist der 1s-Wert der Messunsicherheit. Ergebnis Messunsicherheit Höhe: 1sa = ±0,34 m.

Der gemessene Wert passt gut zum Druckrauschen berechnet aus den beiden LUIS-Stationen (±0,75m). Die Differenz ist wegen der stark unterschiedlichen Messzeit – 30min zu 1 Woche – plausibel.

Algo zur Berechnung der Höhensummen Höhenänderungen werden nur aufsummiert, wenn sie einen bestimmten Schwellwert überschreiten. Der Schwellwert wird als Vielfaches der Höhen-Messunsicherheit angesetzt:

​ Schwellwert = p·SA_h = p·0,75 m

Mit „p“ kann das gewünschte Verhältnis zwischen Fehler erster und zweiter Art eingestellt werden. Mit p=0,67 sind beide Irrtümer gleich wahrscheinlich. Mit p=2…3 wird nur selten bis sehr selten ein Rauschsignal als Höhenänderung einberechnet. Hingegen wird öfter eine echte Höhenänderung als Rauschsignal unterdrückt.

Höhensumme der Route 10vor Graz Der mit o.a. Algo berechnete Schätzwert für die wahre Höhensumme der Runde „10vorGraz“ liegt bei 1773 hm mit einem Unsicherheitsbereich von (1733 … 1801) hm

Dem „wahren“ Wert am nächsten kommt Strava mit 1779 hm.

2 Analysen

In den Analysen werden die jeweiligen Fehlerbeiträge abgeschätzt. Es soll ein realistisches Bild vom Summenfehler und den Hauptbeitragenden entstehen.

2.1 GPS-Höhe oder barometrische Höhe

Die Abb 1 zeigt die prinzipiellen Probleme beider Methoden: die GPS-Höhe hat eine schlechte Präzision (sa=6,98m) und die barometrische Höhe geht mit dem Wetter mit. Die Höhe barometrisch zu bestimmen hat aber zwei Vorteile: (i) der Baro-Fehler ist korrigierbar und (ii) die Höhenauflösung benachbarter Punkte ist um den Faktor 100 besser.

Abb 1: Höhenaufzeichnung über einen typischen Tag bei fixierter Lage (Höhe=const). Die GPS-Höhe streut, die barometrisch bestimmte Höhe geht mit dem Umgebungsdruck mit. Garmin, Messort Gartenhütte. Abtastrate 1/min

Für bestmögliche Präzision der barometrischen Höhenmessung sollte:

• Die Autokalibration mit der GPS-Höhe abgeschaltet und durch einmalige Kalibration beim Einschalten ersetzt werden.
• Bei Pausen das Gerät nicht ausschalten
• Nachträgliche Baro-Korrektur mit den Werten einer ortsfesten Referenzstation

Die Baro-Korrektur ist über die barometrische Höhenstufe Dh/DP sehr einfach durchführbar. In tiefen Lagen ist Dh/DP rund 8 m/hPa. Den exakten Wert liefert die barometrische Höhenformel. Oft sind aber die tabellierten Näherungswerte ausreichend [1].

2.2 Spezifikation Baro-Sensor

Baro-Sensoren werden seit 2014 in Smartphones verbaut. Die häufigsten Typen sind [2]:

• BMP280: iPhone 6/7, Galaxy S6/S7, Xiaomi 5
• BMP180/182: Galaxy Note 2/3, Xiaomi M2, Sony Ericsson Active, Nexus 3/4
• LPS331AP: Galaxy S3, S4

Tab 1: Kernspezifikation des BMP280 [3]

Parameter	typisch	entsprechend	Bedingung
Absolute accuracy *	±1 hPa	±8,5 m	950 …1050 hPa, 0 …+40 °C
Relative accuracy **	±0,12 hPa	±1,0 m	700 … 900 hPa, 25 . . . 40 °C
Offset temperature coeff.	±1,5 Pa/K	±12,6 cm/K	900 hPa, 25 . . . 40 °C
Noise in pressure	±0,2 Pa	±1,7 cm	Filter max, ultra high res.
	±1,3 Pa	±11,0 cm	Filter off, ultra high res.
Pressure resolution	0,16 Pa	1,4 cm	ultra high resolution mode

*) beinhaltet auch den Fehler des herstellerseitigen Kalibrier-Standards
**) Unrichtigkeit des Sensors allein (Kalibrier-Standard ist ideal angenommen)

Je nach Einstellung sind die Rauschwerte gut bis sehr gut. Nicht alle Sensoren sind so gut. Der Sensor in der Wetterstation WS-2090 (Abb 1) hat ein mehr als 10faches Rauschen.

Signifikant könnte der Temperatur-Koeffizient werden. Längere, abwechselnde Fahrten in Sonne und Schatten können mit bis zu 5 °C Temperaturänderungen verbunden sein. Laut Spezifikation würden das 63 cm Höhenschwankungen bedeuten. Die relativ große Zeitkonstante wird den Effekt aber in Grenzen halten.

Für Fehlerabschätzungen sollte das mögliche „Wärmerauschen“ zumindest mit ±33 cm angesetzt werden.

2.3 Barometrisches Rauschen

Jeder kennt die kleinen Wirbelwinde über heiße Flächen, die Staub, Halme oder Blätter kreisen lassen. Das ist der sichtbare Teil von kleinräumigen Instabilitäten in den Luftschichtungen. Diese Instabilitäten sind schnell, sie bauen sich innerhalb weniger Sekunden auf und dauern nur kurz im Minutenbereich.

Die großräumig zu beobachtenden, systematischen Luftdruckänderungen sind deutlich weniger dynamisch. Sie können sehr gut durch 30 min-Mittelwerte beschrieben werden.

Aktuelle MEMS Baro-Sensoren sind außerordentlich dynamisch, die Zeitkonstante liegt im ms-Bereich. Das Rauschen ist von Natur aus hochfrequent. Durch On-Chip Signalverarbeitung ist aber eine weite Anpassbarkeit möglich.

Abb 2 zeigt die die Druckunterschiede von 2 ortsfesten Wetterstationen (EVA700; 0,001 hPa Auflösung) [4]. Auch in den 1/2h-Mittelwerten sind dynamische Druckunterschiede sichtbar. Die Standardabweichung der Differenzen beträgt ±0,125 hPa, entsprechend ±1,1 m. Das ergibt pro Station 1,1/√2 = 0,75 m.

Eine ähnliche Auswertung für die 34,7 km entfernte Wetterstation Deutschlandsberg ergibt eine Standardabweichung der Druckdifferenzen zu ±0,262 hPa, entsprechend ±2,2 m. Hier spielt bereits die großräumige Dynamik der Luftdruckentwicklung hinein.

Abb 2: Druckverlauf von 2 ortsfesten Messstationen des Landes Steiermark (LUIS) über 8 Tage. Die Entfernung zueinander beträgt 3,5 km. Messpunkte sind 1/2 h Mittelwerte, Streuung der Differenzen pro Station: 1sa=0,75m

2.4 Sensorrauschen

Abb 3 zeigt den Versuch, das vom Garmin aufgezeichnete Höhensignal, bei fixierter Lage, in den 3 Anteilen

1. langsame Druckänderungen (Periode: einige 10 min)
2. schnelle Druckänderungen (Periode: wenige Minuten)
3. Sensorrauschen (Periode: einige Sekunden)

aufzuspalten.

Abb 3: Höhenaufzeichnung über 50min bei fixierter Lage (Höhe=const). Die Höhenänderung wird in 3 Anteile zerlegt: (1) langsame Druckänderung (grün); (2) schnelle Druckänderung (rot) und (3) Sensorrauschen (blau). Die orange Linie ist die zeitsynchrone Druckaufzeichnung der Wetterstation „IGRAZ379“. Garmin, Messort im Garten. Abtastrate 1/s. Sensorrauschen 1sa=10cm

Die Auswertung dieser Signale ergab für den Drucksensor des Garmins (RMS Rauschen = Standardabweichung):

RMS-Rauschen Sensor: ±10 cm Das passt recht gut zu den o.a. Spezifikationen.

2.5 Winddruck

Schnelle Fahrt oder Windböen erzeugen am Gerät einen Staudruck, der als Höhenänderung gemessen wird. Zur Abschätzung wird ein Tischventilator 60cm vor dem Garmin platziert und 10x für jeweils 30s ein- bzw. ausgeschaltet.

Ein Effekt ist visuell nicht erkennbar (Abb 4), nur im statistischen Mittel sinkt die Höhe signifikant (p=0,009) um 14 cm. Der 95% Vertrauensbereich liegt bei 4 … 23 cm. Die Höhenänderung durch Winddruck ist vernachlässigbar.

Abb 4: Höhenänderung bei periodischer Staudruckänderung mittels Tischventilator (~5m/s). Der Ventilator wurde 10x für je 30s ein- bzw. ausgeschaltet. Garmin Oregon 650 fixiert.

2.6 Messung des Summenfehlers

Fehlerabschätzungen sind gut für das Verständnis, Sicherheit gibt aber die direkte Messung. Die Methode ist simpel: einen ebenen Rundkurs mindestens 20 Mal fahren. Nach Korrektur des systematischen Baro-Fehlers ist der Mittelwert eine gute Schätzung für den wahren Wert und die Streuung ein Maß für den unsystematischen Summenfehler.

Als Rundkurs wurde der Parkplatz eines Baumarktes in der Nähe gewählt. Feiertags war es einsam genug, damit ein im Kreis fahrender Verrückter nicht auffällt. Das Wetter war optimal: Wind mit Böen bis 17 km/h, Vollsonne und Wolken im Wechsel, Baro durchschnittlich.

Die Auswertung als Bildergeschichte:

Abb 5: (i) Rundkurs 21-mal gefahren Zoom

Abb 6: (ii) Schätzung Baro-Verlauf aus 21 Höhenwerten am Startpunkt und Korrektur Zoom

Abb 7: (iii) Anwendung der Baro-Korrektur auf jedes Höhenprofil Zoom

Abb 8: (iv) Mittelung der Höhenprofile Zoom

Abb 9: (v) Differenzen der 21x gemessenen Höhenprofile zum „wahren“ Höhenprofil. Mittlerer Höhenfehler 1sa=34cm Zoom

Die in Abb 9 dargestellten Residuen zeigen einen generellen Trend, der auf eine suboptimale Baro-Korrektur hinweist. Zwischen den Runden 6 und 11 liegen die gemessenen Höhenprofile zu hoch. Das ist ziemlich sicher auf die Sonne zurückzuführen, die etwa zu der Zeit aus den Wolken kam und die gesamte Asphaltfläche erwärmte.

Während der 21 Runden fiel der Baro um 0,40 hPa (entspr. +3,44m). Die Differenzwerte der beiden LUIS-Stationen lagen bei 1sa = 0,0453 hPa, das entspricht einem Druckrauschen pro Station von 0,28m.

Die Schätzwerte für das wahre Höhenprofil aus der Mittelung:

Minimale Höhe 344,50 m
Maximale Höhe 345,55 m
Kum. Anstieg 1,39 m
Kum. Abstieg -1,39 m
Std. Abw. Höhe (SA_h) 0,34 m
Std. Fehler Höhe 0,08 m

Das bei weitem wichtigstes Ergebnis ist die Standardabweichung Höhe = 34cm. Sie ist etwa 3x so groß wie das Sensorrauschen allein und enthält alle unkorrigierbaren Einflüsse, die während der 21 Runden aufgetreten sind (Abb 9).

2.7 Rauschfilter

Ohne Filter würde das Signalrauschen bei flachen Teilstücken unrealistisch hohe kumulierte An- bzw. Abstiege bewirken. Vor der Dimensionierung des Filters steht die Frage, gegen welchen Fehler man sich primär schützen will: Rauschen als Höhenänderung missdeuten oder echte Höhenänderung als Rauschen missdeuten? Das eine geht immer auf Kosten des anderen.

Zwei Ansätze sind denkbar:

(i) beide Fehler gleich gewichten – mit der Konsequenz im Mittel zwar gut zu liegen, aber eine größere Streuung, insbesondere zu höheren Werten hin, zu beobachten.

(ii) Rauschen sicher unterdrücken – mit der Konsequenz im Mittel zu tief zu liegen, aber eine kleinere Streuung zu beobachten.

Das einfachste Rauschfilter besteht darin, nur Höhenänderungen für die Berechnung des An-/Abstieges zu akzeptieren, die einen Schwellwert überschreiten. Es macht Sinn den Schwellwert als Produkt p·SA_h aufzufassen.

Parameter “p” p=0,67 für „Fehler gleich gewichten“. In der Normalverteilung liegen bei p=±0,6745 ca. 50% der Wert innerhalb und 50% der Werte außerhalb.

P=2…3 für „Rauschen sicher unterdrücken“. In der Normalverteilung liegen bei p=±2…3 entsprechend 5%…1% der Werte außerhalb. D.h. ein echtes Rauschsignal wird nur in 5%…1% der Fälle als Höhe missdeutet. Es heißt aber auch, dass eine echte, kleine Höhenänderung als Rauschen missdeutet wird.

Parameter “SA_h” SA_h ist der mittlere, zufällige Fehler der Höhenmessung. Er setzt sich primär aus Sensorrauschen und Druckrauschen zusammen.

Die Messung des Summenfehlers mit 1sa=±34cm (Abb 9) ist für diese Messung relevant, aber ob der kurzen Beobachtungsdauer von 35min, nicht wirklich repräsentativ. Da ist der 8 Tageswert von Abb 2 mit 1sa=±75cm sicher besser geeignet:

SA_h = 75cm

3 Ergebnisse

Mit dem o.a. Rauschfilter können die kumulierten An- und Abstiege berechnet werden.

3.1 Kumulierter Anstieg Parkplatzrunden

Die Rohdaten sind mit der großräumigen, systematischen Druckänderung korrigiert. Als Streumaß wird die tatsächlich beobachtete Streuung SA_h=0,339 m verwendet.

Tab 2: Kumulierter Anstieg der Parkplatzrunden vs p. Schwellwert = p·0,339m. Zielwert Anstieg: 29,19m

p	k. Anstieg in m	k. Abstieg in m
0	38,90	-38,44
0,67	27,21	-26,74
2	11,12	-10,61
3	5,27	-5,25

„p=0“ entspricht keiner Filterung. Der kumulierte Anstieg ist erwartungsgemäß deutlich zu hoch.
„p=0,67“ kommt dem Zielwert am nächsten
„p=2…3“ liefert erwartungsgemäß deutlich zu tiefe Werte.

Der Garmin Oregon 650 hat als kumulierten An-/Abstieg = 7m bzw. 4m ausgegeben. Offenbar arbeitet der Garmin nach der Methode „Rauschen sicher unterdrücken“ mit p~3

1.1 Kumulierter Anstieg Route „10vorGraz“

Waymarked Trails hat für die Route 10vorGraz – im Vergleich zu anderen GPX Analysatoren – auffällig niedrige Höhensummen ausgewiesen. Die detaillierte Gegenüberstellung war Thema meines vorigen Beitrages.

Ein Leser stellte die Frage, wer nun der Realität am nächsten kommt. Die Frage konnte ich damals nicht beantworten, da mir der wahre Wert unbekannt war. Die Wahrheit kenne ich auch heute nicht, aber ich glaube den richtigen Wert eingrenzen zu können.

Tab 3: Kumulierter Anstieg der Rundtour 10vorGraz vs p. Ohne Baro-Korrektur. Schwellwert = p·0,4m

p	k. Anstieg in m	k. Abstieg in m	(Anstieg+Abstieg)/2
0	1809,6	-1794,4	1802
0,67	1782,0	-1767,0	1774
2	1756,6	-1740,8	1749
3	1742,8	-1727,0	1735

Tab 4: Kumulierter Anstieg der Rundtour 10vorGraz vs p. Mit Baro-Korrektur. Schwellwert = p·0,4m

p	k. Anstieg in m	k. Abstieg in m
0	1800,9	-1801,0
0,67	1773,2	-1773,5
2	1750,7	-1751,1
3	1733,6	-1733,1

Das Streumaß von SA_h=0,4m gilt für den konkreten Tour-Zeitpunkt und stammt aus den LUIS-Daten vom 07.04.20 10:00-15:00. Der Unterschied der Ergebnisse mit dem allgemeineren Wert SA_h=0,75m sind aber nicht sehr groß. Für p=0,67: 1773 hm –> 1763 hm

Der Vergleich von Tab 3 und Tab 4 zeigt, dass die Baro-Korrektur nicht unbedingt erforderlich ist. Bei einem Rundkurs ist das arithmetische Mittel von An- und Abstieg eine ausreichende Näherung für die zeitsynchrone Baro-Korrektur. Für Routen mit unterschiedlichem Start und Ziel korrigiert man An- bzw. Abstieg - vorzeichenrichtig - mit dem Hälftewert der barobedingten Höhenverschiebung.

Der Schätzwert für die wahre Höhensumme der Runde „10vorGraz“ liegt bei 1773 hm mit einem Unsicherheitsbereich von (1733 … 1801) hm.

Dem „wahren“ Wert am nächsten kommt Strava mit 1779 hm. Alle anderen Prüflinge liegen außerhalb des Unsicherheitsbereiches.

4 Referenzen

[1] https://de.wikipedia.org/wiki/Barometrische_Höhenformel#Die_Höhenstufen
[2] https://www.ncbi.nlm.nih.gov/pmc/articles/PMC6022159/
[3] https://www.bosch-sensortec.com/media/boschsensortec/downloads/datasheets/bst-bmp280-ds001.pdf
[4] https://www.umwelt.steiermark.at/cms/ziel/2060750/DE/

10vorGraz ist eine nette, hügelige Radroute westlich von Graz. Die Hauptroute ist ein Rundkurs mit einigen Zufahrten von Graz. In OSM waren ursprünglich alle Wege in einer Relation, mit dem Nachteil, dass Höhenprofil und Weglänge aussagelos waren. Nach Restrukturierung der Relation in Hauptroute und Zubringer sah das Profil schon viel besser aus:

Abb1.: Höhenprofil 10vorGraz Hauptroute (Quelle: Waymarked Trails, route=63364)

Die kumulierten hm waren jedoch überraschend, die Route hat sich nach deutlich mehr angefühlt. Zum Vergleich mit anderen Auswerteprogrammen wurden 3 Datensätze erzeugt:

1. Hauptroute 10vorGraz von WMT runtergeladen. Dieser File hat keine Höhendaten.
2. Mit GPS Visualizer SRTM-1 DEM-Daten hinzugefügt
3. Mit GPS Visualizer SRTM-3 DEM-Daten hinzugefügt

Für eigene Erprobungen können die 3 Files „10-vor-graz-genusstour*.gpx“ hier heruntergeladen werden. Kommentare mit den Ergebnissen sind willkommen.

Abb. 1: Vergleich der ausgegebenen kumulierten Höhenmeter der Route 10vorGraz mit SRTM-1 (30m) bzw. SRTM-3 (90m) Höhendaten. Ausnahmen sind mit *) und **) gekennzeichnet:
*) WMT und Strava verwenden andere bzw. unbekannte Höhendaten; **) Garmin GPS mit barometrischen Höhendaten

Abb. 2: Statistik der kumulierten Anstiege der Route 10vorGraz. Gruppiert nach DEM-Typ. Gruppe 1: nur mit SRTM1 berechnet; Gruppe 2: nur mit SRTM3 berechnet; Gruppe 3: alle DEM ohne SRTM3

Resüme

Die SRTM1 Höhendaten liefern deutlich stabilere Anstiege, als die SRTM3 Höhendaten. Die mit SRTM3 bestimmten Anstiege haben etwa die doppelte Streu-Bandbreite, wobei die Streuung nur nach oben vergrößert ist. Alle Programme, die andere bzw. unbekannte DEM-Daten verwenden, liegen im Streubereich der SRTM1-Daten.

Die 900 hm von Waymarked Trails sind klar als Ausreißer zu bezeichnen, kein anderes Programm liefert auch nur annähernd so niedrige Werte. Der Abstand zum unteren Quartil liegt beim 3,2-fachen des Interquartilsabstandes (übliche Ausreißergrenze: 1,5-fach). Die auffallend starke Glättung des Höhenprofiles könnte eine Erklärung für den sehr niedrigen Wert des kumulierten Anstiegs sein.

Ohne SRTM-3 Anstiege liegt der Median von allen 15 Tests bei 1699 hm. Die barometrische Messungen der beiden Garmins passen mit 1645 bzw. 1735 hm gut dazu. Die Frage welcher Wert dem wahren Anstieg am nächsten kommt, bleibt im Moment unbeantwortet.

Tab 1: Links zu den Programmen

Programm	Links
Waymarked Trails*	https://cycling.waymarkedtrails.org/#route?id=63364
GPX Viewer Kompf	https://www.kompf.de/trekka
GIS.Lab Karten*	http://www.atlsoft.de/gpx/
Show GPX Berkemeier	https://www.j-berkemeier.de/ShowGPX.html
Garmin Edge 1030**	(GPS-Fahrradcomputer)
GPS Track Viewer	https://www.gpswandern.de/gpxviewer/gpxviewer.shtml
QMapShack	https://github.com/Maproom/qmapshack/releases
Deine-Berge*	https://www.deine-berge.de/gps_viewer.php
Garmin Oregon 650**	(GPS-Handgerät)
Strava*	https://www.strava.com
ElevationProfiler	http://geotrekking.de/tools/elevation-profiler.html
IBP index	https://www.ibpindex.com
Trackreport.net	https://www.trackreport.net/
uTrack	http://utrack.crempa.net/
WTracks	https://opoto.github.io/wtracks/

\

Datenanalysen (Auszug)

Die SRTM1- und SRTM3- Test-Tracks haben identische Trackpunkte. Da die Trackpunkte ein Download von WMT waren, ist anzunehmen, dass WMT dieselben Trackpunkte verwendet, sicher ist das aber nicht. Die Tracks der beiden Garmins sind reale Aufzeichnungen auf derselben Route. Diese Trackpunkte sind nach Anzahl und Ort naturgemäß unterschiedlich.

Programm: Show GPX - Online GPX-Viewer

Die Webseite von Jürgen Berkemeier zeigt sehr schön die Unterschiede der SRTM1- und SRTM3-Höhendaten. Im direkten Vergleich erscheinen die SRTM3-Daten deutlich unruhiger. Das ist überraschend, da die SRTM3-Daten mit 90m weniger gut aufgelöst sind, als die SRTM1-Daten mit 30m und damit eher weniger feine Details zeigen sollte.

Möglicherweise erfasst der größere Blickwinkel des Radarstrahles – 3 Bogensekunden zu 1 Bogensekunde – mehr vom rauen Randbereich der Straße. Bei der Berechnung des Anstieges wird offenbar ein Großteil dieser Zacken weggefiltert, ansonsten wäre der Unterschied, in den kumulierten Anstiegen, größer.

Abb. 3: Höhenprofile der Route 10vorGraz mit SRTM1- und SRTM3-Höhendaten. Quelle: Show GPX Berkemeier

SRTM1:
Kumulierter Anstieg: 1643 m
Kumulierter Abstieg: 1644 m
Erfasste Länge: 93,8 km

SRTM3:
Kumulierter Anstieg: 1691 m
Kumulierter Abstieg: 1692 m
Erfasste Länge: 93,8 km

Programm: QMapShack

QMapshack ist ein Desktop Programm zur Planung und Verwaltung von Tracks unter Windows und Linux.

Abb. 3: Höhenprofile der Route 10vorGraz mit SRTM3- (oben), SRTM1-Höhendaten (Mitte) und echte Aufzeichnung mit barometrischer Höhenmessung (unten). Die DEM-Daten (rot) sind oben und in der Mitte ident

DEM- (10m x 10m), SRTM1- und Baro-Höhendaten sind sehr ähnlich, die SRTM3-Daten zeigen hingegen die schon bekannte Störüberlagerung.

Mit unveränderten Einstellungen berechnet QMapshack den kumulierten Anstieg der SRTM3-Daten um knapp 300 hm höher, als mit den SRTM1-Daten. Mit zusätzlichen Filter kann der Unterschied stark verkleinert werden.

SRTM3:
Kumulierter Anstieg: 1980 m / 1710 m (Median 9Pkt) / 1705 m (Interpolation fein)
Kumulierter Abstieg: 1980 m / 1710 m (Median 9Pkt) / 1705 m (Interpolation fein)
Erfasste Länge: 94 km

SRTM1:
Kumulierter Anstieg: 1690 m
Kumulierter Abstieg: 1690 m
Erfasste Länge: 94 km

DEM 10m:
Kumulierter Anstieg: 1710 m
Kumulierter Abstieg: 1710 m
Erfasste Länge: 94 km

Baro von Garmin Edge 1030, Anstieg berechnet von QMS:
Kumulierter Anstieg: 1645 m
Kumulierter Abstieg: 1630 m
Erfasste Länge: 93 km

Rohdaten versus Höhenprofil Waymarked Trails

Die barometrisch bestimmten Höhendaten wurden direkt dem GPX-Track entnommen. Nur die Entfernungen vom Startpunkt wurden aus den Punktkoordinaten errechnet.

Abb. 4: Vergleich der ungefilterten Höhen-Rohdaten „ele“ aus dem GPX-Track mit den Höhendaten von WMT. Route 10vorGraz, GPS Garmin Edge 1030

Wenn WMT dieses Höhenprofil nicht nur zur Anzeige, sondern auch als Grundlage für den kumulierten Anstieg verwendet, ist klar, warum WMT so viel tiefer misst. WMT ist sich dieser Problematik bewusst. Siehe https://cycling.waymarkedtrails.org/help/rendering/elevationprofiles

Das erste Knotenpunktsystem entstand 1995 in Belgien [1]. Von dort breitete es sich nach Holland und Deutschland aus. 2016 war es auch in Österreich soweit: In April wurde das erste – und bislang einzige – Knotenpunktnetz Nimm’s Radl Murtal vorgestellt [2].

Radknotenpunktnetze in Ländern (Quellen: Eurostat [3], knooppuntnet [4])

	Netzlänge km	# Netze	Einwohner	km/100Einw
Holland	38 402	60	17,2 M	22
Belgien	20 601	31	11,4 M	18
Deutschland	21 617	52	82,8 M	3
Österreich	321	1	8,8 M	0

Radknotenpunktnetz Nimm’s Radl Murtal (Statistik von: knooppuntnet [4])

	Netzlänge	# Knoten	# Routen	# Connections
Nimm’s Radl	321 km	101	132	0

Der Vergleich mit einem Spinnennetz ist ziemlich zutreffend. Die Kreuzungspunkte der Weglinien sind die Knotenpunkte. Knotenpunkte sind durchnummeriert und verweisen auf die nächstliegenden Knotenpunkte. Die Planung einer Route von A nach B wird dadurch stark erleichtert.
© Mapillary , baum10; CC-BY-SA 4.0

Drei Jahre nach der Eröffnung – 2019 – gab es in OSM immer noch keine Spur vom Knotenpunktnetz. Verblüffend, oder? Über die Gründe kann ich nur mutmaßen: Zu geringer Bekanntheitsgrad außerhalb des Murtales? Zu viel an Komplexität und Umfang?

Am Anfang stellen sich natürlich viele Fragen, aber echte Schwierigkeiten waren nicht zu erwarten. Schließlich gibt es viele Lösungen in den nahen und fernen Nachbarländern.

Eine echte Hürde war beim Arbeitsaufwand zu erwarten. Es war klar, einer allein wird es nicht in absehbarer Zeit durchbringen. Das musste ein Projekt werden. Am 9.Nov. 2019 wurde über Talk.at [5] das Ziel deklariert und Mitwirkende gesucht. Es war ein Volltreffer, ich fand einen begeisterten Mitstreiter. Das Team war komplett.

„Pläne sind nichts, Planung ist alles“ (Dwight D. Eisenhower), das Motto ist immer ein guter Start. Die Planung hatte 2 Kernthemen:

1. Effiziente Datenerfassung
2. Änderungsfreundliches Tagging

Effiziente Datenerfassung

Das Netzwerk war zu groß, als dass man sich erlauben konnte, die Strecken mehrmals zu befahren. Die Datenerfassung musste daher schon beim ersten Mal vollständig sein. Insbesondere redundante Informationen sollten miterfasst werden, damit auch Beschilderungsfehler erkannt werden können.

Wir konzentrierten uns voll auf die Knotenpunkte. Die Knotenpunktnummer erlaubte eine einfache und sichere Fortschrittskontrolle, die Wegweiserpfeile definierten eine Liste der abgehenden Routen.

Die Daten wurden mit geogetaggten Fotos erfasst. Alle Knotenpunkte wurden mehrmals von allen Seiten fotografiert und auf Mapillary hochgeladen. Dieser Dienst war uns eine sehr große Hilfe. Über die genaue Lage und über die genaue Ausrichtung der Wegweiser relativ zur Umgebung, konnten wir die Wege für die abgehenden Routen bestimmen.

Oft war dasselbe Ziel für die entgegengesetzte Fahrrichtung extra ausgeschildert. Damit war eine zusätzliche Qualitätskontrolle möglich. Der Zielknoten musste auch auf den Quellknoten zurückverweisen. Eine weitere Qualitätskontrolle.

Auf den Routen selbst lag kein besonderer Schwerpunkt in der Datenerfassung. Die GPX-Tracks wurden nicht verwendet. Meist war die Verbindung zwischen den Knotenpunkten ohnehin eindeutig. Ansonsten halfen die Zwischenwegweiser weiter.

Änderungsfreundliches Tagging

Das Tagging-Schema ist das Resultat von 34 analysierten Netzrelationen aus Holland, Belgien und Deutschland. Logik, Häufigkeit und Nützlichkeit waren die Auswahlkriterien für die Überbernahme von Merkmalsbeschreibungen. Das Nimm’s Radl Tagging-Schema ist im WikiProject Austria, Radknotenpunktnetze [6] dokumentiert.

Im Datensatz ist bewusst eine Redundanz enthalten, damit jede Objektklassen auch für sich bearbeitet werden kann. Verbindendes Merkmal für alle Objekte ist das Tag description=Nimm’s Radl*. Struktur und Elemente des Netzes können damit einfach und sicher geändert werden.

Qualitätssicherung

Rohdaten

Alle Rohdaten sind als Fotos in Mapillary verfügbar. Damit kann jederzeit die Abstrahierung verifiziert werden.

Solldaten

Der Betreiber des Netzes hat den Soll-Zustand als PDF-File veröffentlicht [7]. Das ist eine ausgezeichnete Quelle um Differenzen aufzuzeigen und dem vor Ort nachzugehen. Eine Toolkette erleichterte den visuellen Vergleich:

• mit Photoshop pdf –> Tiff-File
• mit QMapTool georeferenziert
• in QGIS als Basiskarte geladen
• mit Overpass Turbo Netz in QGIS geladen

Istdaten

Eine weitere Säule der Qualitätssicherung war das Analysetoolset von knooppuntnet [8]. Die Validierungsliste umfasst 28 Regeln, von „IntegrityCheck“ bis „RouteWithoutWays“. Ein äußerst hilfreiches Werkzeug zum Aufdecken von Fehlern im Netzwerk.

Referenzen
[1] https://de.wikipedia.org/wiki/Knotenpunktbezogene_Wegweisung
[2] https://wiki.openstreetmap.org/wiki/WikiProject_Austria/Radknotenpunktnetze
[3] https://ec.europa.eu/eurostat/databrowser/view/tps00001/default/table?lang=en
[4] https://knooppuntnet.nl/en/overview
[5] https://lists.openstreetmap.org/pipermail/talk-at/2019-November/010399.html
[6] https://wiki.openstreetmap.org/wiki/WikiProject_Austria/Radknotenpunktnetze
[7] http://www.nimmsradl-murtal.info/de/downloads.asp
[8] https://knooppuntnet.nl/en/glossary

Radrouten sind im Prinzip eine empfohlene Sammlung von Wegsegmenten für Radfahrer. Nach dem OSM-Grundsatz „Only map what’s on the ground“ ist deren Eintrag in die OSM-Datenbank nicht so ohne weiteres begründbar. Die empfohlene Route muss ein Abbild in der Realität aufweisen, damit sie in der OSM-Datenbank erfasst werden sollen.

Kennzeichen von OSM-Routen
Eine sehr detaillierte Diskussion ist im OSM Wiki [1] dokumentiert. Die Kernidee:

• durchgehend ausgeschildert
• eindeutig Referenzierbar (Name, Nummer oder Symbol)
• klar definierten Anfang und Ende oder Rundkurs

Abgrenzung zu Radwegen mit Wegweisungen
Ein Radweg mit Wegweisung „Bahnhof 1km“ ist vermutlich keine OSM-Route. Gerade in städtischen Zentren finden sich solche und ähnliche Wegweiser oft an Radwegen. Typisch ist auch die Richtung zu Zentren, zur Peripherie versanden sie. Beim Bahnhof-Wegweiser wäre die nächste Frage: „gibt es auch eine punktgenaue Wegweisung vom Bahnhof hierher zurück?“

Die durchgehende Zielführung einer OSM-Route ist etwas ganz anderes, als die – ev. sogar dichte – Wegweisung zur Orientierung.

Ist es eine OSM-Route?
Die Realität ist nicht ideal, Fehler sind normal, Abweichungen sind normal. Viele OSM-Routen in der Datenbank entsprechen nur annähernd dem Idealbild. Welche Abweichungen können im welchen Ausmaß noch toleriert werden?

Genau hier setzt die Idee einer Routen-Scorecard an. Die Kennzahlen quantifizieren die Ähnlichkeit mit einer OSM-Route und sind damit der erste und wichtigste Schritt. Der nachfolgende Schritt definiert Entscheidungsbereiche.

OSM Cycle Routes Scorecard

Die Schlüsselindikatoren sind kondensierte Stellvertreter für die Merkmale von OSM-Routen. Der Erfüllungsgrad beziffert das Ausmaß der Übereinstimmung mit der OSM-Routen-Anforderung. Der Wert wird in % angegeben, wobei 100% vollständige Erfüllung bedeutet.

Key 1, Durchgehend in beiden Richtungen ausgeschildert
Dieser Indikator ist direkt auf ein notwendiges Merkmal rückführbar. Der Wert ist 100% wenn alle Kreuzungen ausgeschildert sind. Siehe dazu auch [2, Methode Vollständigkeit, S. 2].

Key 2, Anfang und Ziel vorhanden
Dieser Indikator ist direkt auf ein notwendiges Merkmal rückführbar. Der Wert ist 0, 50%, 100% wenn keines/eines/ oder beides vorhanden ist. Bei Rundkurs 100%.

Key 3, Referenzierbar mit Name, Nr. oder Symbol
Dieser Indikator ist direkt auf ein notwendiges Merkmal rückführbar. Der Wert ist 100% wenn eindeutig referenzierbar.

Key 4, Kontinuierliche Zielführung
Dieser Indikator bezieht sich ebenfalls auf das notwendige Merkmal Ausschilderung, bewertet jedoch die bewusste Zielführung im Vergleich zur normalen Wegweisung. Der Wert ist 100%, wenn alle Knotenpunkte (= Kreuzung von Radrouten) mit dem Ziel ausgeschildert sind. Siehe dazu auch [2, Methode Wiederholung des Zieles, S. 2].

Key 5, Offizieller Routenplan vorhanden
Dieser Indikator ist indirekt mit allen notwendigen Merkmalen verbunden. Er ist ein Indiz, ob es eine Idee hinter der Route gibt und verstärkt damit das Gewicht der Zielführung.
100% wenn Karte von offizieller Stelle vorhanden.
80% wenn Anfang, Ziel und einige wichtige Zwischenpunkte offiziell aufgezählt sind.
50% wenn Anfang und Ziel offiziell aufgezählt sind.

OSM-Routen-Score
Der Mittelwert gibt den Erfüllungsgrad der OSM-Routen-Anforderungen an und wird mit folgender Stufung bewertet (s.a. [2, S. 18]):

Wenn der OSM-Routen-Score
<50%: es ist keine Route im OSM-Sinne
>50%: es ist eine Route im OSM-Sinne

Beispiel Radrouten Scorecard der Stadt Zürich

Auszug aus [2, S. 19]:

Die lokalen Velorouten der Stadt Zürich haben eine OSM-Routen-Score von 26% und sind somit keine Routen im OSM-Sinne.

Resümee

Die Scorecard ist ein einfach anzuwendendes Hilfsmittel um Fahrradrouten auf das Anforderungsprofil von OSM-Routen zu testen. Die KRIs (Key Route Indicators) stehen auf einem recht sicheren Fundament. Die Entscheidungsbereiche sind hingegen stärker einer individuellen Argumentation zugänglich.

Der besondere Wert der resultierenden Punktezahl liegt in der begründbaren und nachvollziehbaren Aussage.

Quellen

[1] OSM Wiki: DE:Fahrradroutentagging
[2] OSM User:Robhubi: Analyse der Velowegweisungen in Zürich Stadt, 03. April 2019

Die Qualität der Velowegweisungen in Zürich Stadt wird unterschiedlich gesehen. Diese Analyse versucht eine Objektivierung. Dazu werden die Wegweisungen auf 2 Routen vom See, Nähe Bhf Stadelhofen, zum Hauptbahnhof im Detail betrachtet. Diese Routen wurden gewählt, da sie an Klarheit des Zieles kaum zu übertreffen sind. Für eine korrekte Wegweisung sollte das die leichteste Übung sein.

Inhalt

• Methode
• Überblick – Lage der Knoten
• Ein Knoten als Beispiel
• Ergebnisse
• Resümee

Die Analyse wird hier auszugsweise vorgestellt. Der vollständige Text ist online verfügbar.

Methode

Die Wegweisungen auf den Routen wurden fotografisch dokumentiert. Die Wegweisung wird nach Vollständigkeit und nach Übereinstimmung bewertet. Für die beiden gewählten Routen kommt noch die Wiederholung des Zieles als Bewertungsmöglichkeit hinzu.

Die Wegweisung hat 100% Vollständigkeit, wenn alle möglichen Richtungen eine korrekte Wegweisung haben.

Die Wegweisung hat 100% Übereinstimmung, wenn alle möglichen Zielangaben übereinstimmen.

Die Wegweisung hat 100% Zielwiederholung, wenn ab dem ersten Auftauchen des Zieles „Hauptbahnhof“, alle weiteren Wegweisungen dieses Ziel in Fahrrichtung enthalten.

Überblick - Lage der Knoten

Route 1 „See – Hauptbahnhof“ ist blau markiert. Route 2 beginnt beim „Knoten 1.5“ der Route 1 und führt westlich ebenfalls zum Hauptbahnhof.

Zoom

Beispiel Knoten Stadelhoferplatz – Theaterstrasse

Zoom

Von den 12 möglichen Zielrichtungen sind 5 ausgeschildert (42%). Der Hauptbahnhof wird hier zum ersten Mal genannt.

Es ist nur die Richtung Tiefenbrunnen mehrfach ausgeschildert:

Nach Westen: Bürkliplatz 0 + Enge 0 = 0%
Nach Süden: Tiefenbrunnen 2 + Seefeld 0 = 2/3 = 67%
Nach Osten: Zollikon 0 + Kreuzplatz 0 + Bhf Stadelhofen 0 = 0%
Nach Norden: Hauptbahnhof 0 + Central 0 = 0%
Mittel: 17%

Vollständigkeit: 42%
Übereinstimmung: 17%
Hbf Zielwiederholung: 0 von 1

Ergebnisse

Die %-Ergebnisse werden mit einer in der Statistik üblichen Faustregel in Klassen eingeteilt:

0 < 30% < 50% < 80% < 100 % = kein/ ungenügend / akzeptabel / gut

Testroute 1

Testroute 2

Zusammen

Die Vollständigkeit der Testroute 1 war mit 59% akzeptabel und von Testroute 2 mit 31% ungenügend. Beide Routen zusammen genommen sind in der Vollständigkeit der Ausschilderung mit 49% knapp ungenügend.

Die Übereinstimmung der Wegweiser kann von Testroute 2 nicht bewertet werden, da mit N=1 der Stichprobenumfang zu gering ist. Beide Routen zusammen genommen sind in der Übereinstimmung der Ausschilderung mit 50% knapp akzeptabel.

Beide Test-Routen hatten als Ziel den Hauptbahnhof. Bei Route 1 war sie mit 40% ungenügend und bei Route 2 mit 20% de facto nicht existent. Beide Routen zusammen genommen sind in der kontinuierlichen Zielführung mit 30% als ungenügend zu bewerten.

Resümee

Die Prüfung der Velowegweisungen der Stadt Zürich, mit einer Stichprobe von 14 Knoten, ergab für die Vollständigkeit und Übereinstimmung der Zielbezeichnungen ein Ergebnis an der Grenze zwischen ungenügend und akzeptabel.

Die kontinuierliche Zielführung ist an der Grenze zwischen nicht vorhanden und ungenügend.

---

Bildnachweise

Schilder:
alle Fotos von OSM MrOutdoor, Lizenz CC BY-SA 3.0 CH

Karten:
Open Street Map, © OpenStreetMap contributors;
Open Cycle Map, © Thunderforest And OpenStreetMap contributors ;
Freizeitkarte, © FZK project;
Stadt Zürich Luftbild 2013, Lizenz CC0;

Copyright

Autor: OSM Robhubi; Lizenz CC BY-SA 3.0 AT

(Identischer Text im Kommentar zum Änderungssatz 40059552. Leider kann man dort keine Bilder einfügen, daher hier komplett).

Hi. Beim Planen einer Tour mit Hilfe von Online-Router ist mir in der Gudrunstraße (Nähe Matzleinsdorfer Platz, Wien) eine zunächst unerklärliche Uregelmäßigkeit aufgefallen:

Je nach Router wird im Bereich der Haltestelle auf die Straße ausgewichen oder ein Umweg genommen. Im iD-Editor wird die Haltestelle so dargestellt:

Ich bin jetzt kein OSM/Routing-Experte, aber ich vermute das Problem liegt darin, dass die „Bushaltestelle (Wartebereich)“ den Gehsteig unterbricht. Am Ort gibt es diese Unterbrechung nicht:

Die Haltestellentafel und die Bank sind zurückgerückt und der Gehsteig davor ist frei begehbar. Sollte das nicht auch so gemappt werden? Jemand hat sich sehr viel Mühe gemacht, die Haltestellen so genau zu beschreiben. Daher möchte ich nichts ohne Zustimmung ändern. Vielen Dank für eure Kommentare!