P.S. osm.wiki/Proposal:Separation#Indication_of_adjacent_traffic_mode

FYI Der im Proposal dokumentierte Value für "fließender Autoverkehr" ist "traffic_mode"='motor_vehicle' (du hast hier 'motorized' erfunden ;-).

Was bedeutet denn "smoothness:bicycle" und "surface:bicycle", wenn der path nicht segregated ist? Ist das hier falsch getaggt und es müsste eigentlich "segregated=yes" und "cycleway:smoothness/surface" heißen? osm.org/way/996893384

Hallo vertical212, herzlich Willkommen bei OSM und vielen Dank für deine Adressergänzung in der Roseggerstraße!

Ein Hinweis dazu: In OSM haben wir die Adressen teils als Punkte im Gebäudeumriss, teils stehen sie direkt an Gebäuden. In Berlin, insbesondere der Innenstadt, ist eher die erste Variante verbeitet – so auch hier. Die Adresse gab es also bereits, sie steht aber nicht direkt am Gebäude, sondern in der Nähe seines Eingangs. Das hat nicht nur den Vorteil, dass man direkter zum "Eingang" der Adresse geroutet werden kann, sondern verdeutlicht auch, dass oft nicht nur ein Gebäude, sondern ggf weitere (Hinterhäuser) die selbe Adresse tragen, da sie nicht zu einem Gebäude, sondern einem Grundstück gehört.

Daher habe ich die Adresse hier wieder vom Gebäude entfernt, aber sie ist ja noch als Punkt vorhanden.

Falls du Fragen dazu oder zum Bearbeiten von OSM hast, melde dich gerne!

Beste Grüße
Alex

Ich gehe ganz stark davon aus, dass es nicht mehr existiert und habe es entfernt. Auf dem aktuellen Luftbild (2024) ist zwar noch ein weißes Zelt erkennbar, das es dort vor der Pandemie nicht gab, aber es gibt online keine Spuren mehr davon und die Notwendigkeit eines Testzentrums an diesem Standort hat sich ja erübrigt.

Super, habe ich angepasst! Alles Gute!

Hey, schön, immer mal wieder Changesets von dir zu sehen :) Ich hab ne Frage zu dem Baum hier: osm.org/node/8863258637 – der wurde bestimmt neu gepflanzt?

Vorher stand da nämlich "razed:natural=tree", also ein früherer, entfernter Baum. "razed:" ist ein Konzept, um frühere Zustände zu erfassen, damit User z.B. von älteren (Luft)Bildern nicht Daten ergänzen, die gar nicht mehr vorhanden sind (vgl. osm.wiki/Lifecycle_prefix).

Derzeit steht dort "razed:natural=tree" und "natural=tree" gleichzeitig, aber falls der Baum neu gepflanzt wurde, können wir das "razed:natural=tree" entfernen.

lg, Alex

Where did you get “source=brain” from? Please upload the license of your brain data to the OSM wiki so that the OSM community can check its compatibility with the ODbL.

P.S. Ich habe an dieser Stelle mal einen Hinweis hinterlassen, damit evtl. des Weges kommende StreetComplete-User oder andere Mapper mal die Augen aufhalten können: osm.org/note/4582040

Danke fürs nachsehen! Das dort noch eine Baustellenabsprerrung und keine erneuerte Pflasterung ist, könnte ein Indiz dafür sein, dass die Pumpe evtl. bspw. nach Restaurierung wiederkommt. Gerade bei den historischen Modellen wie hier ist es eher selten, dass sie "ersatzlos" entfernt werden. Daher würde ich nochmal abwarten, bevor ich die Pumpe in OSM als "entfernt" markiere. Bist du zufällig in ein paar Monaten nochmal in der Gegend? :)

Hallo miwie, danke für deine Aktualisierung an einer Berliner Wasserpumpe hier in Friedenau. Du schreibst, die Pumpe wurde abgebaut – heißt das, sie ist gar nicht mehr vorhanden? Dann würde ich sie nämlich mit einem Lifecycle-Präfix versehen (removed:), so handhaben wir es bei anderen abgebauten Pumpen in Berlin (siehe osm.wiki/DE:Berliner_Stra%C3%9Fenbrunnen).
Beste Grüße
Alex

P.S.: Es ist also ein Fall von ATYL (osm.wiki/Any_tags_you_like) in der Hoffnung/als Platzhalter bis sich hier eine Lösung gefunden hat.

Hallo wies1,

uns fehlt in OSM leider ein passender Tag für diese Art von "Parkdeck": "multi-storey" ist für mehrstöckige Parkhäuser gedacht, "underground" für Tiefgaragen passt ebenso nicht, auch ein herkömmlicher "surface"-Flächenparkplatz (eher im Freien) ist es nicht wirklich.

Natürlich könnte man für jeden dieser Tags Argumente finden, warum er aus der Reihe der dokumentierten Tags hier am Besten passt – aber meiner Meinung nach bräuchten wir eher einen spezifischen Tag für solche Parkebenen. Dieses Thema kommt auch immer wieder in Community-Diskussionen auf – zuletzt erst vor wenigen Tagen, wo ich sogar meinen Vorschlag "parking=level" (in einer Reihe anderer Vorschläge) erwähnt habe: https://community.openstreetmap.org/t/undercroft-parking-and-parking-entrances/122724

Als ich damals hier rund um Neukölln eine systematische Parkraumerhebung gemacht habe, habe ich auch andere entsprechende Parkflächen so getaggt, die aber (leider) inzwischen von anderen Usern geändert wurden. Mir fehlt aber gerade die Zeit bzw. habe andere Prioritäten, ein entsprechendes Proposal zu erstellen, daher bin ich da gerade nicht hinterher.

Das ist aber jedenfalls der Hintergrund für dieses Tagging :)

Beste Grüße und noch einen guten Start ins neue Jahr,
Alex

Hallo sundew,

ich beäuge solche Formen des "Remote-Daten-Gärtnerns" auch immer recht kritisch und sichte regelmäßig entsprechende Changesets in meinem Monitoring in Berlin, wo auch kartograph hauptsächlich aktiv ist. Im Gegensatz zu den Änderungen dieser Art einiger anderer User nehme ich seine Changesets eher als guten Beitrag wahr, da er Vorschläge nicht "blind" übernimmt sondern nach Möglichkeit verifiziert und vor allem keine Daten "verbiegt" oder löscht, sondern nahezu ausschließlich anreichert, harmonisiert und korrigiert.

Soweit ich sehe, ist er auch hier so vorgegangen: Ich sehe insbesondere Stolperstein-Harmonisierungen, viele Wikidata-Ergänzungen, in diesem Zuge ein paar Korrekturen und Ergänzungen an POI's sowie ein paar geometrische Korrekturen. @kartograph, ich weiß nicht, ob du bei POI's wie z.B. Geschäften im Einzelfall prüfst, ob sie (z.B. via Mapillary) noch vorhanden sind, kürzlich z.B. via StreetComplete "on the ground" verifiziert wurden oder andere aktuelle Spuren z.B. auf websites etc. vorhanden sind, dass sie noch existieren? Das wäre der einzige Punkt, den ich dabei kritisch anmerken würde. Ansonsten nehme ich wahr, dass die Daten durch den Edit nur besser, nirgends schlechter geworden sind.

In diesem Zusammenhang halte ich @sundew dein Argument für einen Mythos, dass man aus dem letzten Änderungsdatum eines Objekts eine valide Aussage darüber treffen kann, ob ein Objekt noch vorhanden ist. Vielleicht war das in den frühen Tagen von OSM mal ein brauchbarer Anhaltspunkt, heute ist das aber nicht mehr anwendbar. Ja, das liegt insbesondere an vielen remote-Änderungen, die sich jedoch im OSM-Universum zu einem weit verbreiteten und durchaus akzeptierten (!) Mittel entwickelt haben, um Daten systematisch anzureichern und zu harmonisieren, womit sie im Allgemeinen einen wesentlich höheren Informationsgehalt aufweisen und somit die Nutzbarkeit und Analysierbarkeit der Daten erhöhen/verbessern.

Vielleicht fehlt dir ja in dieser Hinsicht das Verständis, welch beeindruckenden Datenanalysen wir dadurch anderen mit unseren OSM-Daten ermöglichen – von lokalen Themen-Karten bis hin zu internationalen Forschungsprojekten. All diese Anwendungen profitieren von möglichst harmonischen Daten (also der möglichst ähnlichen Erfassung ähnlicher Features) und Zusatzinformationen wie Wikidata-Tags, mit denen eine neue Informationsebene eröffnet wird. Mir scheint es leider, als würdest du hier dein eigenes Verständnis durchsetzen wollen und dies durch eher strengen Tonfall und übereilte Revert-Androhung/-Umsetzung durchsetzen.

Ich muss sogar feststellen, dass du @sundew permanent und pauschal solche Changesets du revertieren scheinst. Das sehe ich äußerst kritisch, denn du hast hier ein völlig falsches Verständnis von "mechanischen" Edits. Beiträge wie dieser, über den wir hier konkret diskutieren, muss auch nicht vorher angekündigt oder diskutiert werden – darüber hinaus ist er (siehe oben) nicht ungeprüft. Dein Revert ist dementsprechend eine Reduzierung des Informationsgehalts der OSM-Datenbank und eine Abwertung der Arbeit anderer OSM-Mapper. Ich würde ich dringend bitten, darüber nachzudenken, was du hier tust und ob das hilfreich für die Weiterentwicklung von OSM ist.

@sundew Ich werde deine Änderungen bei Gelegenheit noch einmal näher ansehen (denn ich kenne bisher nur das hier diskutierte CS und den dazugehörigen Revert) und ggf. überlegen, das in der Community bzw. der DWG zur Diskussion vorzulegen. Meiner Meinung nach geht das wesentlich zu weit.

Dennoch ersteinmal einen guten Start ins neue Jahr und nachdenkliche Grüße
Alex

Hallo cyphix1,

herzlich Willkommen bei OSM und vielen Dank für deine Änderungen an der Petersburger Straße! Ich bin gerade über deine aktuellen Änderungen gestolpert und habe mich erst gewundert, warum du viele Objekte gelöscht hast (z.B. Gebäudeeinfahrten, Parkbuchten oder Querungsstellen), aber offenbar wird die Petersburger Straße ja komplett umgebaut (wie ich gerade erfahren habe :) und sie werden also vermutlich nicht in dieser Form wiederkommen. Sollte also soweit passen...

Falls du Fragen zu OSM oder zum Bearbeiten der Daten hast, kannst du dich gern an mich oder andere aus der OSM-Community wenden. Viel Spaß beim Kartieren ;)

liebe Grüße und gute Weihnachtstage,
Alex

Hallo pbnoxious, sehr schöne Frage, da es in diesem Bereich noch nicht sehr viel Dokumentation gibt und daher auch keinen eindeutigen Diskurs/eindeutige Empfehlungen.

Nach meinem Verständnis verhält sich "width" bzw. "width:lanes" hier aber sehr ähnlich zu anderen Tags wie "turn" bzw. "turn:lanes" (siehe auch osm.wiki/Key:*:lanes), wo es ebenfalls üblich ist, die fahrtrichtungsbezogenen Angaben einer eindeutigen Fahrtrichtung zuzuordnen. Das hat den Vorteil, dass es keinerlei Interpretationsspielraum mehr gibt, welche Angabe sich auf welche Spur bezieht. Bei Zweirichtungsfahrbahnen läge es zwar nahe, die erste Angabe auf die – in Linienrichtung gesehen – äußerste/linkeste Spur zu beziehen, da das jedoch in Ländern mit Rechtsverkehr eine Spur ist, deren Verkehr entgegen der Linienrichtung verläuft, kann die Interpretation in manchen Fällen jedoch schwierig werden. Ein überspitztes Beispiel: Man könnte die Schreibweise um die ":start" und ":end"-Suffixe erweitern – z.B. "width:lanes:start=4.5|3" + "width:lanes:end=3|3" – und nun stellt sich die Frage, ob man "start" und "end" in Linien- oder in Fahrtrichtung gesehen interpretieren sollte.

Ich denke, dass diese klarere/eindeutige Interpretierbarkeit der Grund ist, warum sich im lanes-Kontext daher die forward- und backward-Schreibweisen durchgesetzt haben. Bei "turn:lanes" ist dies so dokumentiert (osm.wiki/Key:turn#Indicated_turns_by_direction_and_lane) und auch für "width:lanes" scheint mir das so üblich zu sein, auch wenn undokumentiert: Laut TagInfo wird "width:lanes" derzeit 8.600 mal verwendet, 91% davon in Kombination mit "oneway" (ich gehe davon aus, fast immer "oneway=yes" – dann ist "backward" oder "forward" ja nicht nötig). "width:lanes:forward/backward" gibt es jeweils ca. 3.900 mal, also im Vergleich auch recht häufig.

lg, Alex

Hallo Fabian, toll, so viele neue Bäume in OSM zu sehen :) Welche Quelle hast du denn für die Daten genutzt? Das wäre gut, es in dem entsprechenden Feld anzugeben.

Ein Hinweis zu entfernten/gefällten Bäumen: Es ist ok, sie zu löschen, aber noch besser wäre es, statt dessen den Prefix "removed:" zu benutzen, also die Bäume zu behalten und "removed:natural=tree" draus zu machen (siehe auch osm.wiki/Lifecycle_prefix). Oder "natural=tree_stump", falls noch ein Baumstumpf vorhanden ist. Falls mal jemand mit älteren Luftbildern o.ä. mappt, ist dann nämlich erkennbar, dass der Baum nicht mehr vorhanden ist.

Danke für deine Beiträge und falls du mal Fragen hast, melde dich gerne.

Beste Grüße
Alex

P.S. Die Typos hab ich bereits korrigiert (https://osmcha.org/changesets/159841251).

Hey, du hattest hier zwei kleine Typos drin: Es muss "separate" statt "seperate" heißen und "surface:colour" statt "surface_colour" :) Da du JOSM benutzt: Um genau solche Schreibfehler zu vermeiden, hab ich ein Preset angelegt um eine Autovervollständigung dafür zu bekommen: https://github.com/SupaplexOSM/JOSM-Auto-Complete-Preset. Vielleicht findest du es ja auch nützlich. Lg, Alex

Hallo, danke für die Bestätigung! Bei der Änderung in OSM ist leider ein Fehler passiert, den ich allerdings bereits korrigiert habe: Statt den "erlaubten Zugang" für Fahrräder auf "Nein" zu setzen, wäre die korrekte Variante gewesen, das Feld "Einbahn (Fahrrad)" zu ergänzen und auf "Nein" zu setzen. Oder in "OSM-Tags" ausgedrückt: Statt "bicycle=no" muss es "oneway:bicycle=no" heißen – aber wie gesagt, ich habe es bereits korrigiert. Das ist im OSM-Editor leider nicht sehr intuitiv gelöst.

Bei Fragen dazu, zu OSM oder zum Bearbeiten gern einfach melden – ich oder andere aus der OSM-Community helfen immer gern.

Beste Grüße
Alex

P.S. Zur Dokumentation vgl. auch osm.org/changeset/159289788 – dort hatte ich gestern fälschlicherweise von "oneway:bicycle=yes" statt "oneway:bicycle=no" gesprochen :)