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?

Moin, ich habe die Frage mal ans Forum weitergereicht: https://community.openstreetmap.org/t/entfernung-von-level-0/

Hallo nochmal,

dein Argument mit dem Speicherplatz kann ich grundsätzlich nachvollziehen, aber finde nicht, dass es die Löschungen rechtfertigt. Wenn wir eine Weltkarte bauen wollen, dann wird das nun mal ein bisschen Speicherplatz brauchen. Wenn jeder alles löscht, was er selbst nicht für nötig hält, wird am Ende nicht viel übrig bleiben.

Aber jetzt zum level-Thema: Das sehe ich immer noch anders als du. Dass eine fehlende level-Angabe gleichbedeutend damit ist, dass ein Objekt im EG liegt, könnte überhaupt nur funktionieren, wenn es eine Pflicht zum vollständigen Taggen von Objekten gäbe. Die wird es in einem Mitmach-Projekt wie OSM sicherlich (hoffentlich!) nie geben. Dadurch wird es immer wieder passieren, dass jemand im 3. OG eines Einkaufszentrums ein Geschäft entdeckt und es zu OSM hinzufügt, ohne das level zu taggen. Das sähe dann genauso aus, wie ein Geschäft im EG, das du komplett vollständig getaggt hast. Es wäre falsch, anzunehmen, dass beide Geschäfte im EG liegen. Also bleibt uns nur, ein fehlendes level-Tag als unbekannte Etage zu interpretieren. Dann wissen wir aber auch bei deinem Geschäft die Etage nicht mehr, obwohl du extra auf sie geachtet hast. Ein check_date sagt ja nicht, dass auch alle nicht vorhandenen Tags überprüft wurden. Da bräuchte es schon ein explizites level:check_date, aber an dem Punkt spart man auch keinen Speicherplatz mehr.

Auch wenn deine Interpretation von level=0 als zu entfernendem Default Konsens sein sollte, dann wäre es gut, wenn du dafür sorgst, dass diese dokumentiert wird. Im Wiki zu level finde ich nichts dazu, level=0 ist als ganz normaler Wert dokumentiert (laut Taginfo der häufigste Wert). Solange das der Fall ist, ist das Löschen ein "breaking change" für Anwender wie das erwähnte OpenLevelUp.

(Und nebenbei, auch wenn die Frage der Löschung damit m. E. nichts zu tun hat: Das Bahnhofsgebäude hat nicht nur eine Etage. Das scheint in der Tat falsch gemappt zu sein.)

Außerdem möchte ich dafür werben, bei den Anwendungen der OSM-Daten nicht nur an Karten und Routing zu denken. Unsere Daten sind so mächtig, dass man damit noch ganz viele andere tolle Sachen machen kann, z. B. statistische Auswertungen mit Overpass und wasweißich, wo auch Daten von Interesse sein könnnen, die man auf der normalen Karten nicht "sieht".

Wenn du nichts dagegen hast, würde ich die gelöschten level-Tags darum wiederherstellen.

Das sehe ich nicht so. Wenn es so wäre, ließe sich nicht unterscheiden zwischen Objekten, die im Erdgeschoss liegen, und solchen, für die bisher niemand die Etage eingetragen hat. In großen Gebäuden macht es für mich schon einen Unterschied, ob ich weiß, dass das Geschäft im Erdgeschoss liegt, oder ob es irgendwo liegen könnte.
Zudem werden die OSM-Daten nicht nur in der Standardansicht dargestellt, sondern auch in anderen Karten, wo level=0 relevant für die Darstellung ist (z. B. OpenLevelUp; dort fehlen jetzt die Geschäfte im Hbf).
Ich würde dich darum bitten, solche Tags zukünftig nicht zu entfernen. Auch wenn sie für dich keinen Mehrwert bieten, schaden sie ja auf jeden Fall nicht und andere (ich zumindest) finden sie nützlich.

Hallo Protoxenus, du hast hier mehrfach die level-Tags gelöscht. Warum sollte die Angabe der Etage sinnlos sein?

Moin, das Zs 106 in node/258940089 ist vermutlich ein Fehler?