Brückenhöhen eintragen in die OSM Karte

Vielleicht ist es auch sinnvoll maxheight>=5 anders darzustellen. Ich hatte hier den Fall maxheight=12, gemeint ist aber maxweight=12. Die Stelle kenne ich und konnte es deshalb leicht korrigieren.Ich habe da noch zwei Verdachtsfälle.Da habe ich aber keine Ortskenntnis und muss deshalb den Urheber mal anschreiben.

http://www.openstreetmap.org/browse/way/27064539
http://www.openstreetmap.org/browse/way/87402571

Ich habe keine Vorstellung wie häufig so etwas ist und bei Verwechlungen im Bereich von 0-5 würde es nichts nützen, aber vielleicht könnte man dadurch doch einige Fehler finden.

Gruß Norbert

Hallo Norbert, mmd

Ich stelle mir eine Unterteilung nach Wert ist numerisch, falsch numerisch (Komma statt Punkt), zu groß (>=5), none und unbekannt vor.

Edit: @mmd: Deine Demo-Karte ist gut. Und maxheight=none wird schon andersfarbig dargestellt.

Edbert (EvanE)

Meine zwei Cent: Da in der Nachbarstadt etliche Bahnunterführungen einen halbrundne Querschnitt haben und beispielsweise (links/mitte/rechts) so beschildert sind:
maxheight 3,40 maxheight 3,90 maxheight 3,30,
habe ich die Straße mit maxheight:left=3.40 maxheight=3.90 maxheight:right:3.30 getaggt.

Hallo,

in den Layer “Bereits eingetragene maxheight Tags” habe ich mal eine kleine Fallunterscheidnug eingebaut wie von Edbert vorgeschlagen. Leider gibt es im Moment keine Beispiele in .de für einen falschen Dezimaltrenner, sonst würde das gelb erscheinen. maxheight >= 5 wird blau dargestellt, maxheight=none in grün, gültige maxheight-Werte in rot und ungültige Werte in pink/türkis oder wie immer die Farbe #FF00FF auch heißen mag.

Mit dem Prototyp will auch die Möglichkeiten ausloten, die bisherige Karte komplett auf Overpass API umzustellen. Darin sehe ich gleich mehrere Vorteile:

  • Die Karte ist immer aktuell
  • Karte ist nicht mehr auf Deutschland beschränkt, sondern funktioniert weltweit (ok, da fehlt noch die Übersetzung)
  • Für kleine Änderungen sind keine aufwändigen Anpassungen an der Toolchain notwendig, sondern bestenfalls nur etwas Javascript.
  • Keine regelmäßigen Updates der lokalen Datenbank mehr notwendig

Bisher umgesetzt mit Overpass API:

  • Klon des ito hgv routing layer (hgv=* und hazmat=* farbig darstellen), siehe http://www.itoworld.com/map/160 für die Legende
  • highway mit covered=* ohne entsprechende maxheight=* Angabe
  • tunnel=yes/building_passage ohne entsprechende maxheight=* Angabe

Erst ziemlich eingeschränkt funktionsfähig sind die folgenden beiden Layer:

  • Wege unter Eisenbahnbrücken ohne maxheight=*
  • Unterführungen ohne maxheight=*

Hier vermisse ich die st_crosses Funktion aus postgis. Etwas ähnliches versuche ich mit around aus der Overpass API und nachträglicher Ermittlung der Schnittmenge im Browser. Leider funktioniert auch die geometry.intersects Funktion aus OpenLayers anders als st_crosses. Während st_crosses nur innere Punkte analysiert scheint OpenLayers auch die Anfangs-/Endpunkte mit zu betrachten. Das führt noch zu recht wirren Ergebnissen.

Die Darstellung sieht jetzt auch anders aus. Am Beispiel “Eisenbahnbrücken ohne maxheight” sind die Wege ohne maxheight nun gelb markiert, während die zugehörigen Eisenbahnbrücken blau markiert sind.

Auch von der Performanceseite ist für die letzten beiden Auswertungen noch Luft drin. Ich fürchte, dass ich hier ohne Overpass API-Guru Unterstützung nicht wirklich weiterkomme.

Im Moment würde ich zum Rumspielen mit dem Prototyp (siehe Post #646) empfehlen, die Overlays zu deselektieren, bevor es in eine weiter entfernte Stadt geht - sonst werden zu viele Overpass API-Abfragen abgesetzt. Wenn die Karte nicht mehr geht, könnte ein http://overpass-api.de/api/kill_my_queries weiterhelfen. Damit werden alle zu lange laufenden Anfragen (“runaway queries”) abgeschossen.

Auf jeden Fall sehr positiv ist, dass man viele Karten der Art “maxspeed, maxwidth, maxheight,…” mit Overpass API extrem schnell bauen kann: für den hgv routing layer Klon war das keine halbe Stunde. Wenn man sich nicht gleich ein ganzes Bundesland anschauen möchte, ist das Ergebnis sogar recht performant.

tl;dr

  • Neuer Prototyp: Viele Funktionen aus aktueller Karte als Prototyp mit Overpass API umgesetzt, neue Funktion: aktuell bereits mit maxheight getaggte Wege anzeigen
  • maxheight Karte wie gehabt verfügbar

Für solche Fälle hatte ich hier den Key maxheight:partial vorgeschlagen. Für deinen Fall dann:
maxheight=3.9
maxheight:partial=3.3

Ich denke, die wichtige Information ist, wie hoch ein Fahrzeug maximal sein darf, um die Brücke zu unterqueren und ab welcher Höhe des Fahrzeugs der Fahrer auf Lichtraumprofileinschränkungen achten muss.

Ich denke bei maxheight:partial wäre die Wahrscheinlichkeit höher, dass dies auch jemand auswertet, da es auch auf unspezifischer beschilderte Fälle wie z.B. Lichtraumprofileinschränkung durch Bäume anwendbar ist (maxheight:partial=yes). Auch für Plätze und Parkhäusr wäre der Key geeignet.

Bei left und right sehe ich auch ein gewisses Problem mit dem Vertauschen von links und rechts bezuüglich der Gegenrichtung. Insbesondere wenn dann auch noch unterschiedliche Beschilderungen in den beiden Fahrtrichtungen auftreten, wird es kompliziert.
Bei maxheight:left:backward müßte man wohl immer erst im Wiki nachlesen, ob sich left dann immer noch auf die Richtung des OSM Weges oder die Gegenfahrtrichtung bezieht.

Den Nutzen der Zusatzinformation, die die Unterscheidung von left und right bringt, würde ich für gering halten, da ja auch die Information fehlen würde, wie weit diese Beschränkung ausgedehnt ist.

Ich unterstelle mal: Unterführung == Weg unter einer Brücke.
In der Tat gibt es noch seltsame Ergebnisse. Siehe z.B. bei diese und diese Brücken in Bonn. (Links zu OSM.org, da die Demo noch keinen Permalink hat.)

Du wirst das schon hinbekommen.

Das scheint ein echter Vorteil der (fast Live) Overpass-API zu sein. Zur Perfomance könnte man einen minimalen Zoomlevel festlegen. Der Rhein-Sieg-Kreis mit ein wenig drumherum und Bonn eingeschlossen dauert schon einige Minuten (Eingetragen+Unterführung).

Edit: Ohne Unterführungen/Eisenbahnbrücken ist das eine Sache von Sekunden.

Edbert (EvanE)

Gerade für die falschen Dezimaltrenner sollte man nicht die gleiche Farbe wie für die fehlenden Einträge verwenden, da niemand dazu gebracht werden sollte, eine Brücke nur wegen falschem Dezimaltrenner zu erkunden. Ich denke ohnehin, man sollte das Problem der falschen Dezimaltrenner OSMI oder besser gleich einem Bot überlassen. Dann sollte man den falschen Dezimaltrenner hier einfach als gültige Altenative betrachten. Ebenso sollte eine nachfolgende Einheit “m” mit oder Leerzeichen akzeptiert werden. Wenn du weltweiten Einsatz anstrebst, müssen auch Angaben in Fuß mit akzeptiert werden.
Wenn maxheight >= 5 notfalls schwer von fehlenden Einträgen unterscheidbar wäre, wäre dies nicht so schlimm, da man die Stelle wohl ohnehin aufsuchen muss.

Die Vorteile kann ich nachvollziehen, aber gibt das keine zu hohe Belastung für die Server der Overpass-API? Insbesondere beim weltweiten Einsatz. Derzeit dürfte deine Karte ja noch recht unbekannt sein, so dass dies noch wohl kein Problem ist. Die meisten Mapper dürften schon längst aufgegeben haben, diesen langen Thread mitzulesen.

Einerseits ist diese Darstellung sehr hilfreich, andererseits gibt es auch Probleme:

Sehr zur kurze Wege sind kaum sichtbar. Hier halte ich es (abschaltbar) für sinnvoll, zusätzlich einen Kreis in der entsprechenden Farbe um diesen kurzen Weg zu zeichnen. Wenn oberer und unterer Weg kurz sind, sollte die Farbe es unteren für einen gemeinsamen Kreis gewählt werden.

Die Farben (insbesondere das Gelb) können auch bei langen Wegen Monitor-abhängig erstaunlich gut in der farbigen Mapnikkarte getarnt sein. Dass die Linien natürlich auch Straßenverläufe sind und somit von Position und Lage in die Mapnik-Karte passen, perfektioniert die Tarnung. Ich habe bei mir festgestellt, dass man die gelben Linien von dem von Mapnik für gewisse Straßen verwendeten Gelb in Abhängigkeit vom Betrachtungswinkel mal sehr gut und mal fast nicht unterscheiden kann. Der problematische Betrachtungswinkel ist dabei einer mit sehr kräftigem Bild. Am besten funktioniert die Unterscheidung komischerweise in einem Betrachtungswinkel, wo das Monitorbild schon richtig ausgeblichen ist.

Daher sollte man wohl besser bw-Mapnik als default wählen.
Für farbige Hintergrundkarten wäre wohl eine einstellbare Farbintensität wie bei OSMI hilfreich.

Gegenwärtig gibt es maxheight:left/right viermal öfter als maxheight:partial*…

Wie meinst du das?
Hier ein (leidr symmetrisches) Beispiel:

Du brauchst nur die 5 von dir getaggten Unterführungen anzupassen, dann ist maxheight:partial der einzige verwendete Key. :slight_smile:

Der Key maxheight:partial ist auch noch kein eingeführter Key. Wir haben nur hier darüber diskutiert, das dies eine Lösung für derartige Fälle sein könnte, wobei aber teilweise die Auffassung vertreten wurde, dass es überhaupt nicht erforderlich ist, diese seitlichen Höhenbeschränkungen zu erfassen.

Sieh dir mal auf http://www.drehscheibe-foren.de/foren/read.php?17,4937131
die Brücke auf den Bildern 020 bis 022 an. Da wird es dann schon schwerer mit dem Taggen.
Man könnte in diesem Fall man wohl noch mit dem einfachen left und right arbeiten, aber manche Mapper würden vermutlich anfangen, kompliziertere Konstruktionen mit forward und backward zu bauen, da die seitlichen Höhenbeschränkungen dort formal nur in eine Richtung gelten.
Dann kommt die Definitionsfrage, ob man nun
maxheight:right:forward + maxheight:left:backward
oder
maxheight:right:forward + maxheight:right:backward
oder
maxheight:forward:right + maxheight:backward:right
oder
maxheight:forward:right + maxheight:backward:left
verwenden muss.

Man kann zwar nicht erkennen, was auf den Schildern steht, aber dass die Schilder nur in Fahrtrichtung montiert sind dürfte eher an Gründen der Sparsamkeit als an den Gegebenheiten vor Ort liegen. Ich bezweifle, dass die Höhenbeschränkung aufgehört hat zu existieren, wenn man rückwärts durch die gerade vorwärts befahrenen Brücke fährt.

Man kann Sachen auch unnötig verkomplizieren.

In meinem Fall habe ich das Naheliegendste genommen, um die einmal erfassten Gegebenheiten zu mappen und nicht ein jahrelanges Proponieren abzuwarten.

Ich denke auch, dass :right und :left sinnvoller ist. forward/backward in Kombination mit left/right ist auf jeden Fall doppelt gemoppelt. Wie malenki schon sagt ändert sich ja die Höhe nicht, wenn ich vorwärts oder rückwärts durch den Tunnel fahre.

Hallo,

leider habe ich wegen der Weihnachtstage nicht ganz so schnell antworten können.

Die verwendeten Queries sind bereits die richtigen. Man könnte höchstens überlegen, alle Wege abzufragen und den Schnitttest im Browser zu machen. Es könnte dann aber noch langsamer sein.

Andererseits ist die “around”-Klausel für Wege bisher nur sehr provisorisch umgesetzt und sehr langsam. Da das Feature vorher noch niemand benutzt hat, habe ich es nie optimiert; es testet intern alle Wege der Ausgangsmenge gegen alle Wege in der Bounding Box. Jetzt mit der Karte gibt es aber eine Motivation und vor allem sinnvolle Testqueries, das effizienter zu implementieren. Ich setze mich mal dran, es kann aber ein wenig dauern.

Die Verwendung als Schnitttest ist sehr pfiffig und konsequent. Ich denke, dass das dann als Semantik für “around:0” reinkommt - das vermeidet ein zusätzlichen Syntaxelement, da “around” sowieso einen Schnittest ausführen muss.

Ja, der Hinweis ist angemessen. Generell ließen sich noch die “timeouts” etwas kürzer stellen, dann ist ein solcher Ausfall nicht mehr so wahrscheinlich.

Die Gesamtzahl der Queries ist übrigens nicht entscheidend, sondern die Anzahl der parallel ausgeführten Queries. Nach 1 unmittelbar nach der Versionsumstellung ist aktuell 2 parallele Abfragen die Grenze. Die Serverlast ist durch die Maßnahme so deutlich gesenkt worden, dass es nun wieder reichlich Kapazität zur Verfügung steht. Insofern überlege ich ohnehin, ob nicht eine mildere Beschränkung ausreicht.

Viele Grüße,

Roland

Hallo Roland,

das sind ja ausgezeichnete Neuigkeiten so kurz nach Weihnachten! Ich hatte am Anfang schon Bedenken, dass sich die Schnittoperation gar nicht abbilden lässt und damit wesentliche Teile der bisherigen Karte nicht zur Overpass API gerettet werden können. Die Arbeitsweise von ‘Around’ war mir für Ways nicht unmittelbar klar, ein kurzer Test und Blick in around.cc hatten dann recht schnell zum Ziel geführt.

Die Sache mit den inneren Punkten habe ich in Javascript nachgebildet, so dass die Effekte, die Edbert bereits weiter oben in Post #653 beschrieben hatte, nicht mehr auftreten sollten. Zur Erinnerung: Wege die direkt mit einer Brücke verbunden waren, wurden da noch mitselektiert. Es gibt bestimmt noch einige Ausnahmefälle, in denen das nicht perfekt funktioniert. Kreisverkehre, die mit Brücken verbunden sind, könnten beispielsweise noch Probleme machen.

Ansonsten habe ich den Prototyp noch etwas für IE angepaßt, genauer: Overpass API aufrufen ohne Proxy. Bisher gab es da nur ein “Access is denied” (siehe OpenLayers Bug 719). Die Mapper in “users: Netherlands” scheinen wohl dasselbe Problem zu haben und testen den Workaround in der Zwischenzeit…

@alle: Weiterhin gibt’s ein paar neue Layer, allerdings noch nicht mit sinnvoll ausgearbeitetem Farbschema. Die jeweiligen Werte aus OSM werden zur Kontrolle auch unten links mit angezeigt.

  • Höchstzulässige Breite
  • … Länge
  • … Gewicht
  • … Achsgewicht
  • Höchstgeschwindigkeit für LKW
  • Maut (toll + toll:N3)

Damit sollten die meisten Tags, die sich in irgendeiner Weise auf LKW-Routing auswirken könnten, auf der Karte angezeigt werden.

Maxheight versteht inzwischen auch Angaben in Feet und Inch und ist toleranter gegenüber angehängtem “m”. Ebenso sollten gemischte Angaben (metrisch + englisch) mit Semikolon getrennt erkannt werden.

Viel Spaß beim Testen

Das sieht schon mal deutlich besser aus. Meine beiden Beispiele snd jetzt so wie sie sein sollen. Auch das nähere Umfeld (Anschluss der A 562 an die A 59) sieht vernünftig aus, auch wenn da noch vieles einzutragen ist.

Eine kleinere Ungereimtheit ist mit noch aufgefallen.
An dieser Stelle liegt eine Brücke (layer=2, Rad-/Fußweg) über der Autobahnbrücke (layer=1). Alle drei Brücken sind blau markiert, jedoch keine fehlenden Höhenangaben (die hatte ich letzte Woche ergänzt).
Das ist zwar etwas irritierend, aber sicher nicht dringend.

Die meisten dieser Angaben waren ja in der lange eingestellten Maxspeed-Karte bereits als Layer vorhanden und wurden durchaus vermisst. Insoweit kann ich das nur begrüßen. Fehler sind mir keine aufgefallen.

Nun einige allgemeine Anmerkungen:

  • Ein Permalink kann jetzt gesetzt werden. Prima!

  • Hast du jetzt eine Zeitbeschränkung (ca. 15 Sekunden) drin?

  • Wenn man ein Overlay abschaltet, wird die Anzeige der gefundenen
    Elemente nicht aktualisiert. (Nicht wichtig aber irritierend)

  • Wenn man ein Overlay abschaltet, werden die Daten neu geladen.
    Das scheint mir auf Dauer überflüssig. Auch werden die Zahlen
    des ausgeschalteten Overlays angezeigt.

  • Wenn man Overlays ein-/ausschaltet, zeigt die Anzeige der
    gefundenen Elemente nur die Zahl der letzten Abfrage und nicht
    die Gesamtzahl der Elemente aller eingeschalten Overlays.

  • Die Anzeige der Werte eines Elementes (unten links) beim Hoover ist sehr nützlich.

  • Bei den beiden Brücken-Overlays erfolgt keine Anzeige unten links.
    Vielleicht kann man einfach generisch “(Eisenbahn-)Brücke” respektive
    Weg ohne Höhenangabe” verwenden. Hat man mehrere Overlays
    eingeschaltet, ist es irritierend wenn gelegentlich keine Angabe erfolgt.

Was ich mir für die Zukunft noch wünsche, sind Editor-Links für den Kartenausschnitt oder auch (später) für einzelne angezeigte Elemente.

Ansonsten ist deine Demo-Karte schon weitgehend rund. Sie kann bald in den Echtbetrieb gehen.

Edbert (EvanE)

Wow, gestern Nacht geschrieben, heute Nacht funktioniert es.

Und noch einmal Wow, auch diese Anregungen sind bereits in einem Tag realisert.

Einen guten Rutsch wünscht
Edbert (EvanE)

Super, vielen Dank für’s Testen. Weil man nicht mit zuvielen offenen Sachen ins neue Jahr starten soll, gibt jetzt noch den JOSM Edit Link links unten. Klickt man auf einen Way oder Knoten, wird ein Popup mit weiteren Details sowie einem zweiten JOSM Edit Link angezeigt (beide Features habe ich übrigens bei SunCobalt und misterboo geklaut, danke!).

Brücken mit unterschiedlichem Layer haben jetzt eigene Farben (kompliziertes Beispiel hier - kann bis zu 10 Sekunden dauern, also Geduld). Über den Parameter lang=en werden die Texte in englisch angezeigt, wie beim komplizierten Beispiel zu sehen.

Wünsche ebenfalls einen guten Rutsch :slight_smile:

  • Beide Link-Varianten und das Popup funktionieren (wie nicht anders erwartet).
  • Die verschiedenen Farben je nach Layer sind erst einmal ungewohnt aber nützlich.
    Dein Beispiel ging übrigens flott (wenige Sekunden). Verwendet du einen Cache?
  • Der Sprachumschalter funktioniert ebenfalls.
    Keine Angabe → deutsch Angabe =/= de|en → englisch.
    Sind weitere Sprachen geplant?

Jetzt noch eine wichtige Frage:
An diesem Autobahnkreuz sind alle motorway(_link) als Straße unter einer Brücke nicht markiert. Ist das Absicht, weil das (mindestens in DE) nicht kleiner 4m sein darf, oder ist das ein Versehen. Im ersten Fall, muss bei Erweiterung auf andere Länder geprüft werden, ob dort die Vorschriften (und die Realität) auch so strikt sind.

Edbert (EvanE)

:slight_smile:

sehr praktisch! :wink:

Wir [http://wiki.openstreetmap.org/wiki/Comenius_OSM_and_Tourism] haben in unserem Projekt u. a. den OSM QA Editor http://editor.osmsurround.org/ in verschiedene Sprachen TR, PT, RO und SL übersetzt.
Adrian hat die Anzeige der jeweiligen Sprache über die Einstellungen des Brausers gelöst.

Guten Rutsch haben wir hinter uns, :slight_smile:
deshalb Dir und allen ein “Gutes Neues”

Die Daten werden inzwischen ausschließlich von der Overpass API bereitgestellt und waren wahrscheinlich noch vom Overpass Server selbst gecached. Für die neue Karte benötige ich keine eigene Datenbank mehr, dein Browser redet direkt mit der Overpass API.

Wenn die Oberfläche mal einigermaßen fertig ist, spricht eigentlich nichts dagegen, auch noch weitere Sprachen anzubieten. Wie das geht, sieht man ganz gut hier in der i18n.js Datei am Beispiel deutsch/englisch.

Ja, das ist so gewollt, Bisher wurden motorway und motorway_link nicht berücksichtigt. Darin unterscheidet sich die neue Auswertung auch nicht von der alten. Falls es Länder geben sollte, in denen die false positive-Rate (also Falschmeldungen) nicht zu hoch ist, könnte man ggfs. nochmal überlegen, diesen Fall ebenfalls zu betrachten. Für Deutschland sehe ich bisher diese Notwendigkeit nicht.

Noch zwei andere Punkte:

  1. Beachtung von maxheight nodes, die in der Nähe einer Brückenkreuzung bzw. im Tunnel liegen: im Laufe des Threads gab es abweichende Meinungen dazu, ob Straßen in mehrere Abschnitte aufgeteilt werden sollen oder ob ein Knoten auch schon ausreicht. Ich habe in England in der Stadt Rugby ein maxheight-Tagging gefunden, bei dem das maxheight-Tag nicht am Weg, sondern an einem einzelnen Knoten dieses Weges gesetzt wurde. Dabei befindet sich dieser Knoten in der Nähe der zugehörigen Brücke. Diese Konstellation wird jetzt auch im Overpass API Prototyp berücksichtigt!

Am Beispiel der Crick Road (A428) sieht man, dass an einer Eisenbahnbrücke mit maxheight-Knoten in der Nähe kein Fehler markiert wird, etwas weiter Richtung Nord-Ost wird dagegen ein Fehler markiert, da der maxheight-Knoten zu weit weg liegt. Fehler bedeutet in diesem Falle, dass die Bahnbrücke blau markiert ist, während der Weg darunter rot markiert ist. An diesem Schnittpunkt kann es also zu Problemen kommen. Auf der Karte werden immer die kompletten OSM-Ways angezeigt, die auch mal einen Kilometer oder länger sein können - also immer auf den Schnittpunkt achten. Für Wege mit tunnel=* gilt: ist einer der Knoten dieses Weges mit maxheight getaggt, so wird ebenfalls kein Fehler mehr gemeldet.

Die jeweiligen Werte zu den roten maxheight-Punkten sieht man übrigens, wenn man unten links auf den Knopf “Label ein/aus” klickt.

Ob user:Win32netsky diese maxheight-Knoten auch so in seiner LKW-Karte berücksichtigt, kann ich nicht sagen. Laut seiner Benutzer-Seite im Wiki spricht aber einiges dafür.

  1. Übernahme fehlender Features in neue Karte:

Bisher wurden schon einige Features der alten Karte in die neue, Overpass API basierte Karte übernommen. Was noch fehlt sind:

Suche
Aktuellen Kartenausschnitt und selektierte Layer merken (mit Cookies)
Aktuelle Geoposition ermitteln und Karte entsprechend ausrichten
OpenStreetBug-Integration: Anzeige von Fehlern mit “#maxheight” bzw. Erfassung neuer Fehler direkt aus der Karte heraus
Möglichkeit, die Fehlerstellen als GPX zu exportieren, z.B. für Garmin unterwegs
Mobile Version

Bitte gebt mir kurz Rückmeldung, welche dieser Features mit in die neue Karte überführt werden sollten, oder was eher verzichtbar ist.

Gruß,
mmd

Ah ja, Absicht weil <4m auf Autobahnen nicht zulässig ist.
Das ist bei Eisenbahnen im Grunde genau so. Durch das Lichtraumprofil ist eine Mindesthöhe für Brücken über eine Eisenbahnstrecke klar festgelegt.

Hmmh, gefällt mir nicht, da maxheight eigentlich eine Eigenschaft des Weges/Wegstückes ist.
Aber es ist Sache der Auswerter, ob sie das zulassen wollen oder nicht.

In einer Situation jedoch verwende ich das selber und zwar wenn ein Parkplatz/Parkhaus/Tiefgarage als ein Punkt erfasst ist. Dann erfasse ich die Einschränkungen (maxheight/-speed/-weight) an dem entsprechenden Knoten. Gerade Tiefgaragen kann man ja kaum in ihren Abmessungen erfassen. Es bleibt also bei einem Knoten an der Ein-/Ausfahrt mit allen für die Tiefgarage erkennbaren Einschränkungen.

  • Suche halte ich für wichtig.
  • Ebenso ist das Merken des Kartenausschnitts sinnvoll.
  • OpenStreetBug-Integration: Wenn es nicht zuviel Arbeit macht!
    Die Karte zeigt eigentlich alles in diesem Zusammenhang wichtige.
  • GPX Exportieren: Nett, für mich nicht wichtig.
  • Eine Mobile Version ist mir nicht wichtig. Für andere mag das einen wichtigen Schritt darstellen.

Edbert (EvanE)