Auf Mapillary gibt es ein Foto von dir, das das Schild zeigt: https://www.mapillary.com/app/?focus=photo&pKey=389409799048474 Möglicherweise bezieht es sich aber nicht auf den ganzen Parkplatz, sondern nur den Stellplatz direkt vor dem Haus.

Hallo, das weiß ich leider nicht mehr.

Schön wäre es, aber an der zweiten im Forum angesprochenen Stelle (osm.org/#map=19/48.976604/8.188600) ist es leider umgekehrt.

Reasoning: The state border data provided by the Rheinland-Pfalz surveying office appears to reflect the actual border between Germany and France, codified by the 1925 border treaty, more accurately than the previous French cadastral data.
Further details: https://community.openstreetmap.org/t/grenzverlauf-d-f-bei-lauterbourg/142545
Feel free to point out other opinions or further information on this matter there (also in French)!

Begründung: Die Landesgrenze in Genauigkeit des ALKIS, die das rheinland-pfälzische Landesamt für Vermessung und Geobasisinformation bereitstellt, scheint die tatsächliche Staatsgrenze zwischen Deutschland und Frankreich gemäß Grenzvertrag von 1925 genauer wiederzugeben als die bisherigen französischen Katasterdaten.
Nähere Erläuterung: https://community.openstreetmap.org/t/grenzverlauf-d-f-bei-lauterbourg/142545
Gern dort mit weiteren Hinweisen zum Grenzverlauf melden!

Ich glaube, wir finden in dem Punkt nicht mehr zusammen. Könntest du bitte trotzdem die Löschungen unterlassen, wenn du weißt, dass viele es anders sehen als du?

Moin Protoxenus, du hast hier mal wieder etablierte Tags wie tactile_paving=no, bench=no und bin=no gelöscht. Alle drei werden m. W. von SC abgefragt, sodass sie früher oder später ohnehin zurückkommen werden. Außerdem hat ein Tag wie tactile_paving=no auch einen Informationswert, wie ich finde, aber das habe ich dir sinngemäß ja schon beim letzten Mal erklärt.
Ich weiß, dass du die negativen Tags nicht magst. Du musst sie auch nicht selbst verwenden. Aber könntest du bitte aufhören, die Arbeit von anderen immer wieder zu löschen?

Source should only be "survey".

Ich nehme an, das sind dieselben Daten wie hier:
https://laiv.geodaten-mv.de/afgvk/Geotopographie/Beschreibung?produkt=DVG
Dort steht: "Auf Grund der reduzierten Punktdichte und eines ausgedünnten Inhalts eignet sich dieser Vektordatenbestand besonders für Übersichtszwecke." Deshalb bin ich davon ausgegangen, dass diese weniger genau sind als die Daten aus dem ALKIS.
So richtig verstehe ich aber auch nicht, wie eine "reduzierte Punktdichte" dazu passen sollte, dass da ganze Inseln enthalten sind, die im ALKIS fehlen.
Aber andererseits scheint mir das ALKIS sehr aktuell zu sein (tägliche Aktualisierung im Geobasisdatenportal) und wegen der rechtlichen Relevanz vermutlich auch ziemlich exakt. Ist meine Annahme falsch, dass das Gemeindegebiet genau die Summe aller Flurstücke ist?

https://community.openstreetmap.org/t/verwaltungsgrenzen-an-kustenlinie-geklebt-mv/141275

Danke für deine Rückmeldung.
Du hast recht, dass auf Rügen und Usedom bisher schon die Grenzen an die Küstenlinie geklebt waren. Das ist aber nach meinem Verständnis falsch und die Lösung zur Vereinheitlichung wäre, sie dort zu lösen, statt sie überall sonst auch zu verkleben.
Es stimmt auch, dass die Grenzen von 2005 nicht perfekt waren, sie sind aber immer noch viel dichter an den Grenzen laut Landesamt (die übrigens für OSM freigegeben sind – ein Update wäre also gut möglich) als der reale Küstenverlauf. Das sieht man gut am Darßer Ort oder der Insel Ruden. (Bei letzterer habe ich gestern die Grenze aus dem ALKIS importiert, bevor ich deine Änderungen bemerkt habe.)

Ich glaube, du hast mit deinen Änderungen leider deutlich mehr kaputtgemacht, als dass sie etwas verbessert hätten. Ich werde mich gleich mal ans Forum wenden (Link folgt), weil ein Revert meiner Meinung nach angebracht wäre und ein solcher, glaube ich, schwieriger wird, je mehr Zeit vergangen ist.

Hallo andyblueg, sehe ich das richtig, dass du in diesem und anderen Changesets Gemeindegrenzen löschst und die Verwaltungsrelationen stattdessen an die Küstenlinien klebst? Wenn ja, warum? Das ist genau das Gegenteil von dem, wie es sein sollte, siehe osm.wiki/DE:Grenze#Seew%C3%A4rtige_Kreis-_und_Gemeindegrenze

Hallo Nakaner, hast du dich beim Einzeichnen der Geländer in der Bahnhofsunterführung
way/1428964946
way/1428964956
vielleicht vertan? Auf meinen Fotos vom Juli existiert ersteres überhaupt nicht, zweiteres nur auf einem kurzen Abschnitt unter den Gleisen. Wenn ich mich nicht täusche, ist das auch immer noch so (habe aber nicht genau drauf geachtet).

Moin, wo genau befindet sich der Wegweiser? Ich konnte ihn nicht finden.

(Linienverlauf übernommen aus Relation der S 9)

Hi flagurglehurp! On these two signals
node/13264294249
node/13266265122
you used the key railway:signal:route:design. I think it would be better to use the subkey "shape" instead of "design" as it is part of the international tagging scheme documented at railway=signal#List_of_signal_properties (and also in line with the tagging used in NSW osm.wiki/Australian_Tagging_Guidelines/Railway_Signals#NSW).

Quellvermerk: © GeoBasis-DE/LGLN 2026, Daten geändert

Super, danke!

Hallo, du hast hier vor zwei Jahren ein Zs 10 als Lichtsignal gemappt: node/11772235128
Weißt du zufälligerweise noch, ob das wirklich so stimmt? War vielleicht das Formsignal gemeint?

Das Gebäude hat doch noch ein UG (wo die Toiletten sind) und m. W. auch ein OG. Warum sollten sich dort grundsätzlich keine Geschäfte befinden können?