Autobahnkreuze

Dann würde ich den Vorschlag von @dieterdreist mal ins Wiki übernehmen, ok?

Ich habe einen Vorschlag im Wiki gemacht.

Alle in Deutschland bisher existenten Autobahnkreuze habe ich dem Vorschlag von @dieterdreist umgetaggt auf


name=*
junction=interchange
motorway=yes

Die Auswerte-Seite autobahnkreuz.net ist ebenfalls umgestellt.

Aktuell sind 9 von 138 Autobahnkreuzen in Deutschland gemappt.

Kurzer Zwischenstand: Es sind 32 von 138 Autobahnkreuzen in Deutschland gemappt.

Sind diese Objekte als Fläche gedacht?

Falls ja, sollte dann noch eine area=yes ran?
Denn iD stellt diese Objekte derzeit mehr oder weniger nicht als Fläche, sondern als Linie dar, siehe Beispielobjekt:
https://www.openstreetmap.org/edit?way=802703584#map=16/48.5788/11.5908
Oder ist das ein “Bug” im iD-Editor?

Ich kann mir gerade keinen Fall vorstellen, wo es (bei geschlossenem way) keine Fläche sein könnte. Daher würde ich davon ausgehen, dass es implizit eine Fläche sein sollte bei geschlossenem way, was es als fehlendes Feature des iD klassifizieren würde.

barrier=fence und ähnliche lineare Objekte bilden auch bei geschlossenem way keine Fläche. Da iD das neue Tagging für Autobahnkreuze nicht kennt und area=yes hierfür noch nicht als default definiert ist, halte ich es für folgerichtig, dass iD das auch nicht einfach so annimmt, nur weil es ein geschlossener way ist. Ich meine gar, dass das in Anfangszeiten anders war und iD dafür gescholten wurde.

@Mammi71: Dein Einwand ist richtig. Ich meinte natürlich, dass ich mir im Falle eines geschlossenen ways mit dem Tag junction=interchange keinen Fall vorstellen kann, der nicht als Fläche interpretiert werden sollte, war aber unpräzise in meiner Ausdrucksweise.

OK, so gesehen ergibt das einen anderen Sinn.

was dann trotzdem kein “Fehler” von iD wäre. Die kennen einfach diese Verwendung noch nicht. Also iD anschreiben, dass in diesem Fall von einem default area=yes auszugehen ist. Vorerst ein explizites area schadet nicht.

Ich habe jeweils ein Ticket für iD und JOSM dafür eröffnet.

Das würde bedeuten, auf die entsprechende wiki Seite zu junction=interchange (https://wiki.openstreetmap.org/wiki/Tag%3Ajunction%3Dinterchange) könnten folgende Parameter/Symbole drauf?:

|onNode=yes (Punkt)
|onWay=no (Weg)
|onClosedWay=no (geschlossener Weg)
|onArea=yes (Fläche)
|onRelation=yes (Relation)

https://taginfo.openstreetmap.org/tags/junction=interchange

:slight_smile:

Ja, so sehe ich das. Möchtest Du die Wiki-Seite anlegen?

Ich würde schon das area=yes explizit dransetzen. Es gibt schließlich mindestens ein geschlossenes junction-Objekt (nämlich junction=roundabout), das keine Fläche, sondern ein ringförmiger Way ist. Das heißt, ein Editor muss auf die nächste Ebene absteigen, um zu entscheiden, ob das betreffende junction-Objekt eine Fläche oder ein geschlossener Linienzug ist.

–ks

ich denke, ein Proposal wäre besser gewesen anstatt das gleich als etabliert ins Wiki zu schreiben, bisher ist das ja eher ein Exotentag, während es für „konkurrierende“ Werte schon jeweils zehnmal mehr Objekte gibt.

Ich habe nichts dagegen, da Du dich wohl damit schon etwas länger beschäftigst und Dich diesbezüglich besser auskennst, wenn Du dort die derzeitige Situation (in welcher Art und als was bis jetzt dieses Merkmal in der Datenbank erfasst ist) beschreibst. :wink:

Wäre”? Auf welchem Artikel wurde denn bereits etwas (überhaupt und als etabliert) dokumentiert?

Wie lauten die Konkurruenzwerte? Denn diese Info’ könnte natürlich auch mit in einen etwaigen Artikel zu:
https://wiki.openstreetmap.org/wiki/Tag%3Ajunction%3Dinterchange
Somit würde man erkennen können, dass es ein noch nicht breit “etabliertes” Attribut ist.

Haben wir in OSM noch Demokratie oder schon Anarchie?
Da meint jemand, er weis etwas und meint auch er müsse es sofort in die Datenbank eintragen. Hier reden ein paar Leute über etwas, ohne dass es einen Konsens gibt und einen Tag später wird das deutsche Wiki geändert und sofort die Datenbank zugemüllt mit willkürlich angelegten Objekten, von denen der Ersteller noch nicht einmal weis, ob es Linien, Flächen oder sonst was ist und was dazu gehört, wo es anfängt und wo es aufhört.
Im Wiki gibt es auch keine Beschreibung dazu.
So etwas ähnliches wurde auch einmal im französischen Wiki versucht, aber wieder gelöscht.
In OSM gibt es ja keine Regeln, das Wiki ist noch nicht einmal als Empfehlung zu gebrauchen, da es jeder nach Lust und Laune ändern kann.
Hier versucht man schon Fakten zu schaffen. Die eingetragen undokumentierten Objekte sollten gelöscht werden, auch im Wiki, weil es sonst heißt, “der Vorschlag hat sich bereits in der Praxis etabliert“.
Die Autobahnen im Saarland sind schon überdeckt mit Grasflächen. Jetzt kommt noch eine weitere Fläche/Ebene dazu und die sinnvolle Bearbeitung wird immer komplizierter.
Wem soll so etwas nutzen? Gibt es keine vernünftige Lösung um ein Autobahnkreuz zu beschreiben (als Relation?), statt irgendwelche willkürliche Flächen aufzumalen die auch Wiesen, Wald und andere Objekte beinhalten, wie das hier jetzt praktiziert wurde?
Ein Proposal ist auch nicht gerade demokratisch. Wie erfährt den die Mehrzahl der Beteiligten, außer den wenigen, die hier mitlesen, dass etwas geändert werden soll?
Wenn es dann noch in Englisch ist und die Abstimmung so beschrieben ist, dass sie nicht funktioniert, wie bei “Proposed features/traffic signals=crossing only“ werden die meisten auch davon abgehalten.

ganz so ist es ja nicht, der Schlüssel “junction” ist bereits in Benutzung für die Art von Kreuzung: https://taginfo.openstreetmap.org/keys/?key=junction#values

@Harmor: Ich gebe Dir recht, dass die verklebten Flächen bei den Autobahnkreuzen im Saarland schwer zu bearbeiten sind. Das liegt aber meiner Meinung nach eher am Verkleben. Wenn Du Dir die Autobahnkreuze in Bayern und Baden-Württemberg ansiehst, siehst Du, dass ich dort bewusst nichts verklebt habe sondern immer schön zwischen Straßen-Geometrie und begleitender Gras-Geometrie gezeichnet habe.

Welchen Weg würdest Du vorschlagen, das Tagging zu etablieren?

area:highway=* an landuse=gras (oder “Straßenbegleitgrün”)