Hello, you're right. In the past within this area I added some elevation information in case there there was an elevation information post beside the street. I checked Mapillary for this junction and the mentioned post is missing. So I removed the elevation information again.
Regards

Hello Ceirios,

Thank you for you comment.

Actually in German discussion group there was a post showing some funny traffic sign which this is one of it, just because of equal distances. I wondered how to find that location and I was lucky.

There are some tools which are able to show this destinations sign like natural:

https://osm.mueschelsoft.de/destinations/example/sandbox.htm#country=DE&tags=information=guidepost%0Atraffic_sign=yes%0Adestination:forward=Llantwit%20Major;Llanilltud%20Fawr;Llantwit%20Major;Llanilltud%20Fawr%0Atraffic_sign:direction:forward=312%0Adestination:arrow:forward=left;left;right;right%0Adestination:distance:forward=2.25;2.25;2.25;2.25%0Adestination:colour:forward=white;white;white;white

https://osm.mueschelsoft.de/lanes/render.pl?wayid=1446040631&start=1&country=de

Unfortunately GB signs are yet not included. Result of drawing are of average quality but readable.

Greeting from Dusseldorf
Helmut

In diesem Fall ist es OSM2World.

@aixbrick: Ich finde diese kleine einfache Gruppe MPs herrlich zum Einüben.

Wenn jemand Elemente dieser Gruppe editieren möchte und ein Element selektiert, so findet er zunächst nur Ways ohne jeden Inhalt aber mit dem Eintrag der Zugehörigkeit zu einer Relation. Da sollte auch ein unerfahrener Mapper schon einmal stutzig werden.

Diesen Weg als Mitglied einer oder mehrerer MPs könnte man löschen, wird aber vom Editor verhindert.

Aber man könnte eine Relation und damit eine gesamte Fläche löschen. Unter Umständen bleiben leere Ways zurück. Da schlägt aber beim Hochladen in die OSM-Datenbank das QS des Editors zu, das auf diesen Fehler hinweist. Die leeren Ways wären separat zu löschen, oder man macht seine Änderung rückgängig.

Was bleibt übrig? Man öffnet eine Relation und kann deren Eigenschaften, also die der Fläche, ändern. Unter anderem auch deren Ways löschen. Die Ways werden aber nur in dieser Relation entnommen, die anderen MPs bleiben intakt. Will man diese Änderung speichern, erhält man eine Fehlermeldung des QS, dass die Area nicht mehr über ein geschlossenes Wegesystem verfügt.

Auch dieses Problem ist lösbar, denn alle Ways dieser Relation werden im Editor farblich abgesetzt dargestellt. Die Lücke wird vom Mapper erkannt und kann durch einem neuen Way geschlossen werden, dieser muss aber manuell der MP hinzugefügt werden. Vielleicht ein Knackpunkt, den ich jedoch für nicht allzuschwierig halte. Ignoriert ein Mapper diesen Fehlerhinweis auf ein fehlendes Segment, wird die Lücke von einem Renderer auf kürzestem Wege überbrückt.

Deiner Schlussfolgerung, dass, wenn einzelne Wege gelöscht werden und damit anschließend die MP leer wäre, kann ich nicht folgen. Zumal der Editor verhindert, dass Wege gelöscht werden können, ohne das zugehörige MP zu öffnen. Selbst bei geöffnetem MP wird nur die Zugehörigkeit des Weg zu diesem MP gelöscht, nicht der Weg selbst. Der Weg selbst kann erst gelöscht werden, wenn zuvor alle Relationen zu diesem Weg entfernt wurden.

Ich habe das anders angelegt:

1) Sieben Begrenzungslinien mit acht Knotenpunkten definiert,
2) diese Begrenzungslinien jeweils einem oder mehreren Objekten hinzugefügt:
a) Parkplatz
b) Grasfläche
c) Fußgängerfläche
d) Friedhofsmauer
Die Objekte stellen jeweils eine Relation (Multipolygon) dar.

Die andere Variante wäre:

1) Drei Flächen als Parkplatz, Grasfläche und Fußgängerfläche mit jeweils vier Knoten und vier Linien (also 12 Knoten, 12 Linien).
2) Die Friedhofsmauer mit 4 Knoten und 3 Linien.

Im Editor kann ich bei der MP-Variante jede Fläche und jede Linie einzeln identifizieren und ihre Zugehörigkeit zu den MPs bestimmen. Möchte ich eine Änderung vornehmen, kann ich schon im Voraus bestimmen, welche Auswirkungen sie haben wird.

Bei diesen Varianten versuche einmal, einen Rücksprung für die Friedhofsmauer in der Mitte des südlichen Teils einzubauen. Welche Schritte werden notwendig?

Ihr habt Recht. Ich habe mir ein paar Kreisverkehre in Natura angesehen und die unterbrochene Linie an den Kreisverkehrseinfahrten sind tatsächlich die unterbrochenen Begrenzungslinien der Fahrbahnen der Kreisfahrbahn.

Ich habe mich auch ein wenig von einem Rederer in die Irre führen lassen, der "highway=give_way" als separates Verkehrszeichen und damit doppelt zum Tag "traffic_sign=give_way" dargestellt hat. Zudem steht im deutschen Wiki, dass "highway=give_way" das Verkehrszeichen DE:205 bezeichnen würde. Tatsächlich wird damit aber die Verkehrsregel "Vorfahrt gewähren" beschrieben, die zum Beispiel nach § 10 StVO auch ohne DE:205 an Ausfahrten von verkehrsberuhigten Zonen über abgesenkte Bordsteine auf eine andere Straße gilt.

Im englischen Wiki gibt es dazu wenigsten einen Hinweis, dass zur Positionsbestimmung des zugehörigen Verkehrszeichens zusätzlich "traffic_sign=give_way" zu verwenden ist.

Ich werde meine Tags entsprechend abändern und einen Fehlerbericht für den Renderer erstellen. Weiter wird es notwendig, das deutsche Wiki anzupassen.

Kannst du mir mal die Probleme beim QS bei der Prüfung der Daten beschreiben?

Jeder, der schon mal aneinander verklebte Flächen wegen einer Änderung trennen musste, kennt den Kampf mit den Editoren, wenn man die gemeinsam verwendeten Knoten in zwei getrennte Knoten aufdröseln muss. Je mehr Knoten betroffen sind, umso schlimmer wird es. Am Ende löschte man eine der Flächen und zeichnet sie neu.

Bei einem Multipolygon generiert man lediglich die neue Grenzlinie, löscht die nicht mehr zugehörigen Linien aus der sich ändernden Relation und fügt die neuen Grenzlinien hinzu. Alle Definitionen der stehenbleibenden Fläche bleiben dabei unberührt und werden nicht verändert.

Selbst das Erstellen einer angrenzenden Fläche geht schneller von der Hand, braucht man lediglich die hinzukommende Grenzlinie zeichnen und die zugehörigen Grenzlinien dem neuen Multipolygon hinzufügen. In der Version einer Fläche mit geschlossen umlaufender Grenzlinien müsste man jeden bestehenden Knoten der angrenzenden Fläche suchen und mit einem Knoten der neuerstellten Fläche verbinden. Wie leicht erhält man damit Lücken oder Überschneidungen wenn man einen der vorhandenen Knoten übersieht.

@aixbrick: Bei dem von dir im Kommentar oben beschriebenen Footpath handelt es sich eigentlich um eine Footway Area. Damit habe ich eine flächige Abgrenzung zum Parkplatz mit anderer Oberflächenbeschaffenheit beschrieben. Der Footpath selbst fehlte noch, der ist für das Routing und den Zugangsbeschränkungen der Tordurchgänge relevant. Ob diese Minifläche eine eigenständige Fläche ist, oder ein Multipolygon, ist mir im Prinzip egal. Die Variante mit Multipolygon konnte ich für die Gruppe aus Mauer, Parkplatz, Fußgängerbereich und Rasen schneller und einfacher realisieren.

Die Parkplatzfläche, die Waldfläche und die Grasfläche bilden Multipolygone nach
osm.wiki/DE:Relation:multipolygon#Mehrere_Linienz%C3%BCge_bilden_einen_Ring . Der Fußweg gehört nicht dazu. Sollte es so sein, muss ich das abchecken. Die inneren Ringe, die Grünflächen innerhalb des Parkplatzes, fehlen noch.

Ursprünglich war es so, dass die Waldfläche zugleich auch die Parkplatzfläche bedeckte. Das konnte nicht sein. Ein Multipolygon mit äußerm und innerem Ring war nicht möglich, da die südwestliche Grenzen der zwei Flächen einen gemeinsamen Abschnitt bilden.

Also habe ich in diesem Abschnitt die Grenzlinien an den Kreuzungspunkten unterbrochen, eine der beiden "verklebten" Grenzlinien gelöscht, und den verbliebenen Grenzlinien per Multiplygon den jeweiligen Flächen zugeordnet.

Konsequenterweise bin ich mit der neu hinzugekommenen Grasfläche genauso verfahren.

Mit den nicht verklebten, aber aneinander unmittelbar angrenzenden Flächen und unter Zuhilfenahme der Multipolygone lassen sich nun leichter Grenzverschiebungen, Änderungen oder neue Elemente hinzufügen.

@tux67: Das ist richtig. In diesem Fall jedoch beabsichtigt, um herauszufinden, welcher Tag zu der fehlerhaften Darstellung führt. Da der überflüssige Eintrag zu keinem Fehler führt, habe ich mir erlaubt, diesen Eintrag zu erstellen. Sobald der Renderer eine neue Kachel erstellt hat, schaue ich mir das Ergebnis an und lösche den überflüssigen Eintrag wieder. Gegebenenfalls kann ich so einen detaillierten Fehlerreport für den Renderer schreiben.

Hi, da gibt es einen Renderer der mir den Kreisverkehr teilweise mit zwei Spuren dargestellt hat, obwohl lanes=1 und junction=roundabout gesetzt waren. Ich schaue gerade, was der Fehler sein könnte. Ich lasse das oneway=yes zunächst bestehen, bis der Renderer diesen Kartenausschnitt neu erfasst hat. Wenn es das wäre, kann ich einen entsprechenden Fehlerreport schreiben.

Die Motorwaylinks am nördlichen Kreisverkehr kommen auch noch dran, stehen auf meiner Liste.

Entsprechend deiner Ausführungen sind also die Endstücke, derzeit als Secondary oder Primary gekennzeichnet, zu Motorway Link zu ändern. Gleichzeitig ist (in diesem Fall) der Tag zone:traffic=DE:rural oder alternativ motorway=no hinzuzufügen. Gegebenenfalls sind noch Access Tags abzuändern.

Während die Auswirkungen der Tags zone:traffic=* und motorway=yes auf der Hand liegen, erschließt sich mir die Bedeutung von motorway=no nicht. Aber diese Diskussion würde ich lieber auf Wiki fortführen.

Dem Vorschlag, den Teil des Motorway Links ohne anzuwendende Autobahnregeln mit einer anderweitigen traffic:zone=* zu markieren, kann ich folgen und werde mein Changeset entsprechend abändern.

Ich darf kurz aus dem OSM-Wiki zitieren:
"..gelten auf den Rampen die gleichen Verkehrsregeln wie auf den Autobahnen selbst."
osm.wiki/DE:Tag:highway%3Dmotorway_link

Default Access Restrictions für einen Motorwaylink sind:
access=no; motor_vehicle=yes; hgv=yes; surface=paved

Dazu kommt StVO § 18 Abs. (9) "Zu Fuß Gehende dürfen Autobahnen nicht betreten", also auch nicht kreuzen.

Das führt mich dazu, den Beginn bzw. Ende eines Motorwaylinks nicht mit dem Zusammentreffen der quer verlaufenden Zufahrtsstraße zu definieren, sondern mit den Verkehrszeichen DE:330.1 bzw. DE:330.2. Das passt auch mit StVO Anlage 3 (zu § 42 Absatz 2)
Richtzeichen Abschnitt 7 Zeile 16 und 17 zusammen: "Ab diesem Zeichen gelten die Regeln für den Verkehr auf Autobahnen."

Ähnlich wird auch das Ende bzw. der Beginn eines Motorwaylinks an Autobahnpark- und Raststätten mit dem Ort des Wechsel der Verkehrsregeln bestimmt.

Autobahnrampen bleiben Autobahnrampen, auch wenn der Motorwaylink nun an anderer Stelle beginnt bzw. endet. Mit der Verschiebung des Endpunkte wird aus der Karte sichtbar, ab welchem Punkt der Rampe die Autobahnregeln beginnen bzw. enden.

Das mit der Verkehrsbedeutung ist schon korrekt. Was mir jedoch wichtiger ist, ist die Änderung der Gesetzeslage. Ab dem Autobahnschild gilt ein generelles Halteverbot, weiterhin dürfen keine Fußgänger und Radfahrer mehr die Ab- oder Auffahrrampe überqueren. Der Überweg an der gegenüberliegenden Seite des Kreisverkehrs wäre rechtlich nicht mehr möglich.

Dass das Routing nicht mehr korrekt ist, halte ich für ein Problem des Routers. Obwohl technisch unmöglich, geht der Router vermutlich von einer Autobahnrichtgeschwindigkeit auf der Auffahrrampe aus und liegt damit erheblich über der maximal erlaubten Geschwindigkeit auf einer Landstraße.

Als weiteren Schritt möchte ich noch Direction-Tags hinzufügen, sodass nur die rechte Spur der L11 auf die Autobahn Richtung Düsseldorf weist. Ich befürchte jedoch, dass die Routing-Engine diesen Hinweis ignorieren wird. Was aber wiederum ein Problem des Routings ist und nicht ein OSM-Datenbankfehler.

What's about to add
loc_name[:<xx>] -> osm.wiki/Tag:loc_name:en=...
and
int_name[:<xx>] -> osm.wiki/Tag:int_name:en=...
according to
osm.wiki/Names

Although tracks are often rough with unpaved surfaces, this tag is not describing the quality of a road but its use. Consequently, if you want to tag a general use road, use one of the general highway values instead of track.

See OSM-Wiki at highway=*

Thank you to re-add the tracks.

Although tracks are often rough with unpaved surfaces, this tag is not describing the quality of a road but its use. Consequently, if you want to tag a general use road, use one of the general highway values instead of track.

Some of the way reclassified to track are actually tertiary roads as they are connecting smaller villages and settlements.

highway=*

OSMCowboy deleted clear visible and regularly used tracks on dry riverbeds connecting allotments and farms to each other. Try to use Mapbox satellite images to verify. Even ways are used only during dry season they shouldn't be deleted.

Du hast vergessen zu erwähnen, dass eine Ladesäule nur in der Zeit Jan-Nov nutzbar ist :-D