Danke fürs wieder hinzufügen. :-)

Hallo und willkommen bei OSM,
genau das - hat sonntags zu - war bereits eingetragen: "Su,PH off" ([Su]nday, [P]ublic [H]oliday = Feiertage). Du hast diese Angabe nun entfernt.
Gruß

Nein, falsch ist es nicht, aber der Verzicht aufs Aufteilen reduziert die Fehleranfälligkeit, da man nur den Kreisverkehr als Ganzes hinzufügen muss. Bei Aufteilungen muss man genau darauf achten, welche Teile hinzugefügt werden müssen, außerdem muss deren Reihenfolge stimmen (gilt natürlich auch für andere Relationen, wie Wanderwege, Radrouten...). Gerade bei Fahrplanwechseln oder neuen Linien ist das ziemlich aufwendig. Ich bin da Unterstützer des https://de.wikipedia.org/wiki/KISS-Prinzip :-).

Hallo,
um dir (und nachfolgenden Mappern) die Arbeit zu erleichtern: Es ist nicht nötig, Kreisverkehre für Relationen aufzuteilen. Das muss nur gemacht werden, wenn sich beim Kreisverkehr Eigenschaften ändern (z.B. unterschiedliche Anzahl Fahrspuren).
Gruß

Danke, ich habe noch "boundary=hazard" ergänzt: changeset/165544053.

Hier sind auch viele neue Punkte entstanden, die lagegleich mit vorhandenen waren (daher bin ich überhaupt hierauf aufmerksam geworden).
Bei den Wegen ist "flood_prone=yes" getaggt. Das kann ggf. ausgewertet und ein entsprechender Hinweis in der App angezeigt werden ("Weg ist" möglicherweise überschwemmt.").
Ansonsten stimme ich pitscheplatsch zu: Die Wege sind vorhanden und würden irgendwann ohnehin wieder erfasst. Daher rückgängig gemacht mit changeset/165328869.

Hello,
"bus:backward" and "bus:forward" are unnecessary. There is already "bus=yes" tagged. If the router does not understand that, adjust it to do so, instead of changing OSM data.
Regards

Hallo,
"landuse=recreation_ground" halte ich in Verbindung mit "military=danger_area" für widersprüchlich, da die Fläche hier eben nicht der Erholung dient/dienen kann. Ich würde hier stattdessen "abandoned:landuse=military" nutzen (so war das auch schon mal getaggt).
Gruß

Hallo,
ich hatte hier die Gebäude von "construction" auf " yes" geändert. Da ich nicht erkennen konnte, ob die Hausnummern nach Fertigstellung (noch) stimmen (Luftbild zeigt zwei Gebäude, ALKIS ist nicht aktuell), habe ich die Nummern erstmal gelöscht und ein "fixme" eingetragen.
Danke fürs wieder ergänzen.
Gruß

Mapping those connections are the least you have to do (and I think that should solve the problem in that case, thank you).

Mapping sidewalks separatly is a long time discussion in the community but the most say that only the existence of a curb is definitevly not enough to map a separate way. In my personal opinion I would also avoid separate ways even if there is a parking lane or trees because if there is no car parked you a are able to cross the street (even between cars) and for me tree areas are only relevant if they have a certain size (so you just could not walk around them).

And there is another (maybe minor) routing problem: Because the separatly mapped ways do not have names, a router could not tell you "Turn right into Steppenbergallee", instead it would only say "Turn right". Adding the street name to those ways could be a solution but is highly disputed.

Hello,
before adding more and more sidewalks as separate ways, please note that they are already tagged on the street, for example way/30091143 ("sidewalk=both"). There is no need to draw them as separate ways as long as they are not physically separated from the street. Draw them as separate ways can also lead to routing problems: osm.org/directions?engine=graphhopper_foot&route=50.768819%2C6.029437%3B50.768334%2C6.032878#map=19/50.768514/6.031682 (note the strange behaviour at the red marker).
Regards

Ich habe noch einige Tags korrigiert bzw. ergänzt: changeset/165038048.
von einer Verlängerung bis zur Adenauerallee würde ich abraten, da der Fuß-/Radweg nicht baulich getrennt verläuft und das zu Routingproblemen führen kann. Die Erfassung mit Tags an der Straße ist etabliert, siehe auch osm.wiki/DE:Bicycle/Radverkehrsanlagen_kartieren.
Und noch ein Hinweis zu Google Earth und Streetview: Beides ist zur Nutzung bei OSM nicht erlaubt, siehe osm.wiki/Google.

Wendeverbote gelöscht mit changeset/165029915.

Zum Vergleich (Fußgänger):
Graphhopper ist schon aktualisiert:
osm.org/directions?engine=graphhopper_foot&route=50.751009%2C6.109428%3B50.750577%2C6.110579
Wenn man von Westen kommt, soll man nun rechts abbiegen und dann wieder links.

OSRM zeigt noch den alten Verlauf (keine Ahnung wie lange noch):
osm.org/directions?engine=fossgis_osrm_foot&route=50.751009%2C6.109428%3B50.750577%2C6.110579
Hier folgt man dem Kornelimünsterweg und wird dann schräg auf den Weg geleitet.

Die Frage ist nun: Was entspricht mehr der Realität (https://www.mapillary.com/app/?lat=50.750821061111&lng=6.10976425&z=17&focus=photo&pKey=332099148777809)? Eigentlich doch das ursprüngliche Mapping, oder?

Ich würde eher way/24342758/ bei node/1918315237/ enden lassen, way/181397126/ dort aufsplitten und beim vorderen Teil das "oneway" entfernen. Dann die Tags wieder an way/519693146/ ergänzen und die Relationen anpassen.
So wie es jetzt ist, stimmt es nämlich auch nicht, z.B. ist die Oberfläche von way/24342758/ im Bereich der Wendefläche nicht "compacted".

Danke

Hallo,
du schreibst "improve". Worin besteht diese Verbesserung?
Aktuell sehe ich hier
- Doppelte Daten (Bürgersteig als Weg und als Tag an der Straße).
- Beim Weg fehlt die Angabe, dass es ein getrennter Fuß-/Radweg ist (ist bereits an der Straße erfasst, s.o.),
- Die Radroute relation/13333706 führt über way/1377607856, der aber nicht für Radfahrer freigegeben ist,
- Bei node/9949514534 endet aus Richtung Osten kommend die Radfahrer-Freigabe plötzlich.
Gruß

Hallo,
das ist nur eine Zufahrt zu einem Haus, also "highway=service" mit "service=driveway". Eine solche Zufahrt hat auch typischerweise weder Name noch Geschwindigkeitsbegrenzung.
Gruß

:-)

Hallo,
ich glaube, du hast dich in der Stadt vertan.
Gruß