Straßen - viele Keys und Suffixe, eine Übersicht

Hallo,
für Straßen und straßenbegleitendes Tagging (access, destination, sidewalk, parking, …) gibt es sehr viele Tags und die Kombination mit den vielen Suffixen macht die Sache nicht gerade einfacher. Ich habe begonnen, eine Übersicht zu erstellen, welche Tags es gibt, welche Kombinationen mit Suffixen möglich sind und wie die korrekte Reihenfolge im Key lautet.

http://wiki.openstreetmap.org/wiki/User:Mueschel/Stra%C3%9Feneigenschaften

Über Anmerkungen und Ergänzungen würde ich mich freuen!

Man kann es auch kompliziert machen, wenn es einfach geht.

Ich finde, die Hälfte der Tags ist Tagging für Router.

Erstmal ein guter Ansatz, habe mich aber noch nicht durch alles durchgearbeitet …

und gibt es u.U.Überschneidungen mit

http://wiki.openstreetmap.org/wiki/Attributierung_von_Stra%C3%9Fen_in_Deutschland ?

Das hoffe ich doch - es dreht sich jedenfalls um die selben Keys. Der Link beschreibt eher wann welches Tag eingesetzt wird, während ich vor allem eine Übersicht über die Tagging-Möglichkeiten geben will.

Das ist nur eine Zusammenstellung von etabliertem Tagging. Den wirklich unübersichtlichen Teil mit parking:lane:* habe ich noch gar nicht beschrieben.

Gern. Wie würdest du denn eine Straße mit Richtungsfahrspuren, unterschiedlichen Höchstgeschwindigkeiten und Zugangsbeschränkungen auf den Fahrspuren einfacher abbilden?

Jetzt bin ich aber gespannt, was daran schlecht ist.

–ks

Kurze Anmerkung, weil ich grad nicht die Zeit fürs Wiki habe:
Für maxheight gibt es auch :left und :right. Ein Anwendungsfall ist hier zu sehen.

Kann man da als LKW-Fahrer nicht einfach “ab durch die Mitte”?

Ja, aber nur wenn nix entgegen kommt.

Was heißt :left und :right? Wie weit ragt das in die Fahrbahn hinein? Ich würde da ja einfach das hier taggen - auch nicht perfekt, aber zumindest auswertbar:

lanes = 2
lanes:conditional = 1 @ height>3.4
maxheight = 4

@Prince Kassad: Das machen die LKW-Fahrer in aller Regel (mit Warnblink an).

@Thomas8122: In der Regel brauchen die LKWs nur den Platz, um in die Mitte einzuscheren. Wenn sie dort sind, passen PKW bequem vorbei.

@mueschel: :left und :right bezieht sich natürlich (wie alle diese Angaben) auf die Richtung des Weges, an dem die Tags stehen.
Was ist am derzeitigen Zustand nicht auswertbar? An deinem Vorschlag wäre zu kritisieren, dass die 3,60m Höhe aus einer Richtung unter den Tisch fallen und die conditional lane in der Realität nicht sichtbar ist. :slight_smile: (Und du wirst jetzt sicher sagen wollen, dass die durch die Höhenangabe in der Mitte ausgeschildert ist.)
Zudem ist “meine” Version einfacher zu mappen und zu merken: Einfach die vorhandenen Höhenangaben mappen, fertig.
Otto Normalmapper wird wohl kaum auf die Idee kommen, aufgrund der Höhenangaben eine dritte, virtuelle lane zu mappen.

Was :left und :right heißen, weiß ich. Aber normalerweise beziehen diese sich auf den Fahrbahnrand und nicht auf eine nicht angegebenen Teil der Straße selbst. Wie breit ist der Teil auf den sich :left und :right beziehen?

Das linke Schild konnte ich nicht lesen. Lass das aber bitte in einem anderen Thread diskutieren.

@mueschel: Den knapp drei Jahre alten Thread findest du hier.

Von mir: Danke für die Arbeit.

Wir mappen für den Anwender (und damit auch für den Router) und da kann eine solche Aufstellung schon mal helfen.

Wenn ich bedenke, was sich alles für Dinge in der Datenbank finden, können bei Straßen ein paar mehr Daten doch nicht stören. Ich freue mich, wenn es Anwender (und auch Router) gbt, die die gesammelten Daten auch nutzen, ohne “Kopfstände” machen zu müssen.

Kleine Kritik: Unter “Radwege” steht in der Tabelle was von “Gehwege” (ist sicher ein copy-and-paste-Fehler) - einfach berichtigen und schon ist er weg. :wink:

Gruß Uwe

@:mueschel: Ich finde deine Arbeit sehr lobenswert, ohne das ich im Moment die Zeit hätte, das durchzuarbeiten und ggf. Mängel aufzuzeigen.
Vielleicht wäre es sinnvoll, wenn du alles fertig hast (Ich weiß “fertig” wird’s nie), dieses “Pamphlet” offiziell ins Wiki zu legen (oder wie immer du es richtig hälst) und entsprechende Hilfs- und Querverweise in den nötigen OSM Wikis erstellst. Wichtig für Neueinsteiger und Wiki-Forscher innerhalb unserer OSM, um sich einzuarbeiten. Danke dir für dieses Engagement.

Danke, die sind mir durchgerutscht. Scheint aber auch die Mehrheit der Verkehrsteilnehmer so zu sehen: Rad wird auf dem Gehweg gefahren und auf dem cycleway werden die Autos geparkt :wink:

Das können wir gerne machen.

Die Breite der Einschränkung ist natürlich nicht definiert. Die wichtige Information ist aber, dass es dort eine EInschränkung gibt, die die Aufmerksamkeit der Lkw-Fahrer erfordert (Lkw-Navi kann warnen) aber die Durchfahrt höherer Fahrzeuge nicht verhindert.

Persönlich würde ich maxheight:partial bevorzugen. Im Falle des Beispielbilds dann z.B. maxheight:partial:forward=3.6 und maxheight:partial:backward=3.4. Maxheight:partial hätte den Vorteil, dass man auch Einschränkungen in Straßenmitte (z:B.Straßenbahnoberleitung) mit erfassen kann.
Die exakte Lage der Einschränkung wäre dann eher etwas für Flächentagging. Area:highway müßte aber erweitert werden, um sowas abdecken zu können.

Width und width:lanes sollte man vielleicht als zwei unabhängige Basisschlüssel darstellen, denn hier bedeutet das .lanes ja nicht nur eine spurabhängigkeit des Wertes, sondern definiert die Bedeutung des Wertes auch von der Straßen- zur Spurbreite um.
So kann man width:lanes=3|3|3 nicht einfach als width=3 abkürzen, was bei allen anderen Basisschlüsseln aber erlaubt wäre.
Konsistenter wäre stattdessen ein Schlüssel lanewidth, der dann nochmals den Zusatz :lanes bekommen könnte, wenn die Spuren unterschiedlich breit sind.

Der Schlüssel width ohne lanes ist leider wertlos, wenn eine Straße Rad- oder Gehwege hat, da im Wiki nicht sauber definiert ist, welche Straßenbreite width bezeichnet (Fahrbahnbreite? Volle Breite inkl. Rad- und Gehwegen?).
Auch andere Interpretationen von width wären möglich, wie die Breite des gewidmeten Straßenraums oder die bauliche Breite inkl. Böschungen. Da wir Damm oder Einschnitt als Teil des OSM-Weges taggen, könnte man letzteres durchaus als Breite dieses Objektes ansehen.

Ein Tag oneway:end=yes wäre grundsätzlich sinnvoll, um unechte Einbahnstraßen (nur Verbot der Einfahrt von einer Seite ausgeschildert) zu taggen.

Den Schlüssel lanes mit :start oder :end zu kombinieren, wäre auch grundsätzlich denkbar. Dass das allerdings einen sinnvollen Nutzen hat, sehe ich aufgrund der zu :lanes inkompatiblen Zählweise noch nicht.

Die Schlüssel lit, cutting und embankment fehlen noch in der Aufstellung.

Einfacher - und unabhängiger von der Deutungsfähigkeiten des Routers/Renderers - wäre es, die Straße einfach dort zu teilen, wo die Einbahnigkeit endet.

Auch einfach, und noch richtiger wäre es, Abbiegerelationen zu verwenden um das Verbot der Einfahrt zu taggen.