Hallo und willkommen bei OSM,
bitte keine Namen anpassen, damit es auf einer Karte besser oder anders angezeigt wird. OSM ist eine Geodatenbank, aus der auch Karten abgeleitet werden können (osm.org/ ist dabei nur eine Möglichkeit). Das Objekt ist bereits als Gedenktafel getaggt (memorial=plaque). Wie die Darstellung auf den Karten aussieht entscheidet der jeweilige Ersteller, er kann z.B. das Wort "Gedenktafel" automatisch voranstellen oder den Namen gar nicht anzeigen.
Bitte ändere daher die Namen hier und bei den anderen Gedenktafeln wieder zurück.
Gruß

Hallo,
schön , dass du die fehlende Haltestelle hinzugefügt hast :-). Allerdings einige Hinweise dazu:
- Für Haltestellen im AVV gibt es Empfehlungen zur Erfassung: osm.wiki/DE:Aachener_Verkehrsverbund. Pro Richtung gibt es jeweils eine "stop_position" (auf der Straße, sprich dieser ist Teil des Wegs), außerdem eine "platform" neben der Straße als einzeln stehender Node. Normalerweise reicht dies zur Erfassung. In seltenen Fällen, zumeist bei "wichtigen" Haltestellen, werden diese als Weg (Wartebereich) angelegt (z.B. Mariadorf Dreieck).
- Beide Elemente (Nodes) müssen der jeweiligen Linienrelation an der richtigen Stelle hinzugefügt werden. Du hast die Elemente hier bei der sog. "Master-Relation" eingetragen. Diese dient aber nur der Zusammenfassung der einzelnen Linienrelationen.
- Du hattest hier außerdem eine Abbiegebeschränkung hinzugefügt, die das Geradeausfahren verbietet. Das verhindert ein Routing und ist wohl so nicht beabsichtigt gewesen.
Ich habe die Haltestelle angepasst und die Abbiegebeschränkung gelöscht: changeset/159322185.
Gruß

Kein Problem, ich habe die wiederhergestellt: changeset/159283623.

Hallo,
du hast hier die stop_positions der Haltestelle "Im Boich" gelöscht. Gibt es dafür einen Grund? Laut Fahrplan existiert die Haltestelle und wird angefahren.
Gruß

OK, that will make updating a lot easier.
Do you know https://ptna.openstreetmap.de/? Maybe you should contact @ToniE because Belgium is missing there and your tool could possibly be a good addition.

Hello,
in my opinion it doesn't make sense to add an relation for a route which is just a partial route of an already mapped (longer) one: relation/1514949.
As I scroll your changeset history I see that you are adding more route variants to bus lines. Please keep in mind that all those routes have to be checked on every timetable change. Lot of work...
Regards

Hallo und willkommen bei OSM,
mit "amenity=parking_space" wird ein einzelner Stellplatz (auf einem Parkplatz) markiert. Das ist aber bestimmt nicht das, was du wolltest, oder?
Den Parkplatz gibt es übrigens schon: relation/17016276.
Gruß

Zu location: Wir haben hier genauso eine Doppelnutzung, wie bei "service". Beide Tags werden in unterschiedlichen Fällen genutzt. Meiner Meinung nach sollte man so etwas vermeiden, auch um eine eidneutige Zuorndung zu haben. Was ist denn das Gegenteil von "indoor=yes"? "indoor=no" oder eher outdoor=yes"? Oder doch besser "location=outdoor": outdoor=* (3. Absatz)? Und StreetComplete hält sich auch nicht unbedingt ans Wiki. SC setzt bei Bücherschränken offenbar "indoor=yes", amenity=public_bookcase empfiehlt aber "location=indoor".
Normalerweise müsste man einmal grundsätzlich (international) zur Diskussion stellen, ob man sich von "indoor" zugunsten von "location" verabschiedet und "indoor" ausschließlich für Indoor-Tagging genutzt werden soll.

Hi,
ich habe auch nur den Artikel der Rheinischen Post gefunden. Demnach soll die Brücke "Ende November" wieder befahrbar sein. Mehr weiß ich auch nicht.
Gruß

Rückgängig gemacht mit changeset/158491508.

Hallo,
du hast bei jedem Gebäude "amenity=school" ergänzt. Es gibt hier aber keine 17 Schulen, sondern 3 und diese sind bereits als Fläche eingetragen. Außerdem gehört auch nicht der Schulname an jedes Gebäude. Ich habe das daher rückgängig gemacht (changeset/158243908), "school:gender" habe ich dabei auf die Fläche übertragen.
Gruß

Hallo,
du hast hier mehrere Gebäude gelöscht und dann (grober) neu gemappt. Dabei sind gleich drei Adressen verlorengegeangen: Aachener Straße 208, Nickelstraße 6b und 6c. Die Gebäude und Adressen waren nach ALKIS erfasst und existieren offenbar noch. Auch die aktuellen Luftbilder (NRW Orthophotos) zeigen keine baulichen Veränderungen im Vergleich zu ALKIS.
Was ist also der Grund dieser "Anpassung"?
Gruß

Hallo,
osm.wiki/DE:Tag:amenity%3Dpost_office ist für reine Postfilialen gedacht, die direkt durch den Postdienstleister betrieben werden. Das ist aber nur noch selten der Fall. Zumeist bieten Geschäfte (wie hier die Tankstelle) die Dienstleistung neben ihrer Haupttätigkeit an. In diesem Fall wird seit 2021 das Taggingschema für "Postfiliale im Einzelhandel" angewendet und die Daten am POI des Geschäfts erfasst.
Die Daten sind also nun bei node/146683011 eingetragen.
Gruß

Hallo,
leider gibt es hier mehrere Probleme:
- Die Baustelle befindet sich nicht auf der Brücke, sondern im oberen Teil, Richtung Kreuzung.
- Die Straße ist nur in eine Richtung gesperrt, siehe https://www.regionetz.de/ueber-uns/presse/baumassnahmen/?tx_news_pi1%5Bnews%5D=2860&cHash=756e8f7d999d864412173dd1463702ea
- Mit dem Tagging highway=construction schließt du alle Verkehrsteilnehmer aus, also z.B. auch Fußgänger. Diese sind von der Sperrung aber gar nicht betroffen. Das Tag wird normalerweise nur für komplette Sperrungen/Straßen im Bau verwendet, siehe osm.wiki/DE:Tag:highway%3Dconstruction.
- In OSM werden Baustellen i.d.R. nur eingetragen, wenn sie mindestens mehrere Monate dauern (zumeist länger als 3 Monate). Das hängt mit den Anwendungen zusammen, die die Daten nutzen.
Ich habe die Änderung daher rückgängig gemacht: changeset/158016083.
Gruß

Es ist nicht zweimal derselbe Tag, siehe osm.wiki/DE:Key:destination.
"destination[:forward/backward]" kommt auf den Weg hinter der Kreuzung, "destination:lanes[:forward/backward]" auf den Weg vor der Kreuzung. Wenn der Weg sowohl von einer Kreuzung abzweigt und seinerseits wieder an einer endet (mit Fahrspurmapping), dann werden beide Tags erfasst.
Und noch ein Wort zu JOSM: Bitte nicht immer darauf verlassen, dass ein Editor alles richtig macht oder erkennt. Nur weil er etwas nicht kennt, ist das nicht automatisch ein Fehler.
Ich habe die Kreuzungen wieder auf die ursprüngliche Geometrie zurückgeändert (sofern das nicht bereits erfolgt ist): changeset/157995925.

@9ix: Ich habe das im Forum zur Diskussion gestellt, weil ich mir nicht vorstellen kann, dass das "destination"-Tagging z.B. bei osm.org/#map=19/50.543228/6.255933 im vorherigen Zustand (Straßen, die im rechten Winkel abzweigen) nicht funktionieren soll. Wenn das so wäre, müssten viele Kreuzungen weltweit anders gemappt werden.

https://community.openstreetmap.org/t/geometrieanderungen-wegen-fehlerhafter-destination-auswertung/120183

Gut, dann frage ich nochmal direkt: Gibt es für die o.g. Änderungen an den Kreuzungen einen Grund?

Und noch was: way/537842370: Auch hier wurde an der Geometrie etwas verändert. Ob diese und die anderen Änderungen Einfluss auf das Routing haben, müsste Flo beantworten. Ich halte sie zumindest für fragwürdig, da sie z.T. nicht der Realität entsprechen.

Korrektur: Der letzte Link sollte dieser sein: way/537835344/. Verlinkt wurde die "Pseudospur".

Mir sind folgende Änderungen aufgefallen:
- way/537821265/: War vorher im rechten Winkel an der Straße Dreistegen gemappt.
- way/439496110/: Eine Fahrt von der Straße Perlenau geradeaus ist nun nahezu unmöglich.
- way/1323214539/: Wie oben bei Dreistegen. Zusätzlich mappst du aber noch eine Pseudospur, die es nicht gibt.