"drinking_water:legal=yes/no" ist ein üblicher, im Wiki beschriebener Tag für genau diesen Zweck (ist ein Hinweis "[Kein] Trinkwasser" angebracht?). Wenn da kein solcher Hinweis angebracht war, dann schreib gern "drinking_water:legal=unsigned" ran ;)

Wie du sicher weißt, wird in Ländern wie DE so ein Hinweis oft pauschal an Wasserquellen angebracht, unabhängig der tatsächlichen Wasserqualität. Die Berliner Bezirke bringen diese Hinweise mal an den Brunnen an, mal nicht. Ob es da eine Korrelation mit den tatsächlichen Prüfergebnissen gibt, entzieht sich unserer Erkenntnis. Und da wir, wie beschrieben, keinen Zugang zu den Prüfergebnissen bekommen, können wir auch keine Aussage zu "drinking_water" treffen. Ich weiß jetzt auch nicht, was daran "verantwortungslos" sein sollte, die Prüfergebnisse da nicht ranzuschreiben, da mir das im Krisenfall vermutlich relativ egal ist bzw. ich dann selbst beurteilen kann, ob ich die Brühe abgekocht trinken will oder lieber zu einem anderen Brunnen gehe. Bei Schwermetallen o.ä. wird so ein Brunnen sicher stillgelegt.

Wie auch immer - ich kann nicht ändern (bzw. habe es erfolglos versucht), dass StreetComplete-User massenhaft "drinking_water=no" anbringen. Also was ist jetzt eigentlich das Problem..? Und was soll der Hinweis mit der Spree? Wäre mir neu, dass das eine Infrastruktur der Trinkwassernotfallvorsorge ist..?

Der originäre Zweck dieser Brunnen ist, Menschen in Notsitutationen (emergency) mit Trinkwasser (drinking_water) zu versorgen. Sie sind eine formelle Infrastruktur der Trinkwassernotversorgung. Das solche Notsituationen extrem unwahrscheinlich sind und der Anspruch an die Wasserqualität dann andere sind, steckt gewissermaßen im Tagging.

Daher würde ich auch keinen Widerspruch zu "drinking_water=no" sehen, da die "Definition" von drinking_water in diesem Fall eine andere ist.

Unabhängig davon gehört "drinking_water=no" eigentlich nicht an die Brunnen. Das wird leider überwiegend durch StreetComplete-User gemappt - korrekt wäre "drinking_water:legal=no", wenn sich ein entsprechender Hinweis am Brunnen befindet. Die Brunnen werden nämlich regelmäßig behördlich geprüft und haben in vielen Fällen sogar reguläre Trinkwasserqualität. Diese Daten sind für uns aber leider nicht zugänglich.

Hey, warum hast du "emergency=drinking_water" an diesem Straßenbrunnen entfernt? Die Brunnen dienen der Notwasserversorgung und wir haben uns in Berlin darauf geeinigt, dieses Tagging an allen 2000 Brunnen dieser Art zu nutzen. Habe es daher wieder ergänzt. Siehe auch osm.wiki/DE:Berliner_Stra%C3%9Fenbrunnen. LG, Alex

Hallo, kein Problem, habe die Änderung am südlichen Straßenstück wieder rückgängig gemacht. Mit dem JOSM-Editor geht das ganz gut. Es ist aber auch nicht schlimm, das entsprechende Wegstück einfach noch ein zweites mal zu ändern - technisch/in der OSM-Datenbank läuft das letztendlich auf das gleiche hinaus. Liebe Grüße! Alex

Hallo Zkwosch,
auf dem südlichen Abschnitt der Glitschiner Straße hast du den Radweg mit StreetComplete auf "nicht vorhanden" geändert, obwohl es zumindest im Juni noch einen gab (https://www.mapillary.com/app/?pKey=720020772539803). Gab es da eine Veränderung oder war das ein Versehen?

lg, Alex

Erledigt das osm.org/note/3268323?

Hallo momabebra,
hier wie auch an anderen Stellen hast du - vermutlich unabsichtlich - Gehweg-Informationen reduziert. Das Problem: An Straßenlinien gemappte Gehwege haben öfter mal, so wie hier, Eigenschaften wie "sidewalk:*:bicycle" oder "sidewalk:*:traffic_sign". Diese überträgst du bei deiner Separierung von Gehwegen allerdings nicht. StreetComplete löscht diese Informationen dann später, wenn du die Gehwege in der entsprechenden Quest als "separate" markierst. Das ist also einerseits ungünstig durch SC gelöst, vor allem aber unaufmerksam bei deiner Gehwege-Kartierung. Bitte achte zukünftig darauf, dass solche Informationen nicht verloren gehen!

lg, Alex

Hallo geozeisig,

warum hast du den den Status "Landschaftsschutzgebiet" am Pfuhlgelände an der Britzer Straße entfernt?

lg, Alex

Hallo Ilian,
du mappst ja gelegentlich neue Fahrradständer, auch solche, die zunehmend in Berlin im Fahrbahnbereich entstehen. Daher wollte ich dir mal einen Hinweis auf das Tagging "bicycle_parking:position" hierlassen, womit man insbesondere Fahrradständer auf der Fahrbahn mit ""bicycle_parking:position=lane" genauer mappen kann (siehe auch osm.wiki/Proposed_features/bicycle_parking:position).

Das Tagging haben wir in Berlin entwickelt und nutzen es auch aktiv für Auswertungen zur Verkehrswende oder beispielsweise in dieser Parkraumanalyse: https://parkraum.osm-verkehrswende.org/

beste Grüße
Alex

Hm, schade, dass SC "sidewalk=separate" statt "sidewalk:both=separate" draus macht. Dann kann man sich nie sicher sein, dass beide Seiten gemeint sind... Weißt du, ob es dazu schon eine Diskussion/Ticket gibt?

Habs korrigiert.

Hey,
wenn ich es richtig verstanden habe, ist "building=terrace" (was du hier zahlreichen Gebäuden gegeben hast) die "schlechtere" Variante für Reihenhäuser, denn sie wird verwendet, wenn man alle Häuser in einem Umriss zeichnet. Wenn allerdings jedes Haus für sich gemappt ist - so wie hier - dann ist "building=house" die richtige Wahl. Ich werde diese Änderung also demnächst wieder rückgängig machen (ist nicht aufwendig). Siehe osm.wiki/Tag:building%3Dterrace bzw. auf deutsch osm.wiki/DE:Tag:building%3Dterrace.
lg, Alex

@cargo bikes in Berlin: I have now added the new tag "bicycle_rental=institutional" for the cargo bike rental system in Berlin, as "bicycle_rental" describes the type of a rental station, not the type of bike that can be rented ("rental=cargo_bike" is fine for that). None of the "bicycle_rental"-types documented so far fits otherwise, as this are not "rental stations" in the stricter sense, but rather a rental system connected to locations.

Die verschieden zusammenhängenden Gebäude sind genau in dieser Form auch in den Berliner Liegenschafts-Kataster-Daten (ALKIS) enthalten. Dieses ALKIS-System steht in Berlin unter einer OSM-kompatiblen Lizenz, d.h., wir können diese Daten als Grundlage zum Mappen benutzen. Gerade bei Gebäuden wird das sehr oft genutzt, da die Grundrisse der Gebäude da viel genauer erkannt werden können als auf Luftbildern (die oft einen Höhenversatz haben). Höchstwahrscheinlich hat jemand die Gebäude hier also aus den ALKIS-Daten "abgemalt" - aber ob der Unterschied irgendwelche baulichen Gründe hat oder "Willkür" ist, kann ich nicht beurteilen. Wenn man auf Luft- oder Schrägluftbildern genau hinschaut, kann man sehen, dass die Gebäude unterschiedlich sind - also vielleicht hat es tatsächlich bauliche Gründe... Aber wie auch immer: Im Prinzip ist die derzeitige Kartierung kein Problem, da die Gebäude ja durchaus zusammenhängen. Auch wenn eine Trennung ebenso möglich wäre. Das ist immer Auslegungssache, aber macht eigentlich kaum einen Unterschied.

Die Adressen sind in diesem Fall als Punkte gemappt, was in Berlin so auch vielerorts üblich ist. Das mit den Adressen ist gar nicht so einfach, da wir sie zwar "Hausnummern" nennen, aber es eigentlich "Grundstücksnummern" sind. Sie sind also nicht zwingend einem Gebäude zugeordnet bzw. insbesondere in den Gründerzeitvierteln Berlins sind oft mehrere Gebäude auf einem Grundstück mit einer Nummer (meist Vorderhaus, Hinterhaus etc.). Da ist die Kartierweise mit dem Punkt vorteilhaft, da man den Punkt dann einfach da hinsetzen kann, wo man als "Besucher" nach dieser Hausnummer/einem Klingelbrett suchen würde, also ungefähr da (innerhalb des Gebäudeumrisses), wo sich auch der Eingang mit dieser Hausnummer befindet. Es ist also nicht nötig, die Nummern auf die Gebäudeumrisse zu verteilen. - Ja, auch wenn es nicht "einheitlich" aussieht, denn direkt gegenüber an der Hirtsieferzeile sehe ich alle Adressen an den Gebäuden. Aber beide Varianten sind für Suche, Navigation und auch Datenanalysen problemlos auswertbar. (Ich persönlich finde die Variante mit dem Punkt besser, da man den Punkt in jedem Fall präziser in Nähe eines Eingangs platzieren kann und damit im Zweifelsfall nicht zur "Rückseite" eines Gebäudes navigiert wird, wenn man danach sucht, aber das scheint Geschmackssache zu sein.)

Hallo,
herzlich Willkommen auch auf diesem Wege ;) Ein kleiner Hinweis zur Verwendung von "building:part": Du hast hier (und an weiter nördlich an der Tankstelle) "building:part" an Gebäudeumrissen, die eigenständig für sich selbst stehen, zusammen mit "building" genutzt. "building:part" ist aber eher eine Art technisches Konzept in OSM, um Gebäudeteile innerhalb von Gebäudeumrissen abzugrenzen. Hier an diesem Gebäude über dem Supermarkt ist es z.B. korrekt an dem kleinen, nördlichen "Turm", der etwas über den Rest des Gebäudes hinausragt - allerdings nur, wenn sich dieses kleine Rechteck innerhalb des Gesamtumrisses des Wohngebäudes befindet. Es sollte also kein "eigenständiges" Rechteck sein, da es ja rein baulich ohnehin zum Wohngebäude gehört. Den einstöckigen Supermarkt kann man dann als eigenständiges Gebäude mit "building" mappen, aber ohne "building:part". (Ich habe das bereits korrigiert.)

Siehe auch im OSM Wiki: osm.wiki/DE:Key:building:part

lg, Alex

Das können wir gern machen - ich bin nur leider fast nie dort und werde es auch die nächsten beiden Male nicht schaffen (Urlaub, anderer Termin). Hab mich beim letzten Mal geärgert, dass ich es nicht in Olivers Garten geschafft habe - aber vielleicht klappts ja mal wieder.

Ich hoffe nur, du brichst solange keinen edit war vom Zaun, wenn ich die crossings hier - verbessert und korrigiert - wieder einarbeite? ;)

Noch etwas in anderer Sache, wenn ich dich schonmal "an der Strippe" habe: Liest du noch im Matrix-Kanal mit? Hatte dich dort neulich mal angepingt, weil ich mich dunkel erinnere, dass du mal einen Kontakt zur Stelle hattest, die die Orthophotos bereit stellt und alle gespannt auf die neuen Bilder warten. Vielleicht weist du ja mehr? Hattest du letztes Jahr nicht sogar schon vor Veröffentlichung OSM-nutzbare Luftbildressourcen aufgetan..?

lg, Alex

Hallo Tom,

lass uns die Problembereiche trennen: (1) Sinnhaftigkeit von separat gemappten Gehwegen und dessen handwerkliche Umsetzung - da hat sich in den letzten Jahren in OSM glaube ich viel verändert und es wäre vermessen, an dieser Stelle darüber zu diskutieren (bei Bedarf z.B. hier: osm.wiki/Berlin/Verkehrswende/Gehwege oder auf den "globaleren" Seiten dieser Art). (2) Die Berechtigung von "hw=crossing" an den Nodes hier in diesem Fall.

Ich leite mal kurz her, warum ich eine deutliche Berechtigung für letzteres in diesem Fall sehe. In OSM mappen wir "hw=crossing" an Stellen, die zum Queren für Fußgänger "vorgesehen" sind. Das ist hier der Fall, denn es handelt sich um Verbindungen von Gehwegen im Kreuzungsbereich. An diesen erfordert zumindest die StVO eine besondere gegenseitige Rücksichtnahme (eben weil das Queren "vorgesehen" ist); abbiegende Fahrzeuge müssen querenden Fußgängern sogar Vorrang gewähren. Ein "Aufmerksamkeitssignal an den Fahrer" ist also durchaus gerechtfertigt, selbst wenn man es aus dieser Straßen-Routing-Perspektive betrachtet - im Gegensatz zu sonstigen beliebig einmündenden Fußwegen, an denen "hw=crossing" tatsächlich nichts zu suchen hat, wenn keine baulichen Merkmale vorhanden sind. Aber Querungsstellen an Kreuzungen sind eben rechtlich wie von der "Aufmerksamkeit" der Verkehrsteilnehmer aus gesehen grundsätzlich verschieden davon.

Das es an diesen Stellen neben der Kreuzung und der Führung der Gehwege keine besonderen baulichen Merkmale gibt, ist mMn unabhängig davon zu betrachten. Das kann sich ja auch schnell ändern, wenn beispielsweise taktile Platten oder Gehwegvorstreckungen am Bordstein verbaut werden (was hier im Industriegebiet vermutlich noch dauern dürfte ;). Zumindest ein "crossing=unmarked" sollte also auf jeden Fall ergänzt werden, um eine qualitative Unterscheidung zu Ampeln und anderen markierten Querungsstellen zu ermöglichen (was der User vielerorts auch verwendet hat, nach dem ich ihn darauf hingeweisen habe, hier offenbar (noch?) nicht. Ich habe mir, nebenbei bemerkt, sogar eine Art "Debug-Layer" gebaut, in dem "hw=crossing" ohne "crossing=*" neben anderen offensichtlichen "Fehlern" rund um Neukölln ausgeworfen werden und die ich gelegentlich verbessere.) Dann kann auch ein Router zwischen "offensichtlichen" und "nicht-offensichtlichen" (je nach Perspektive ;) Querungsstellen unterscheiden und Hinweise entsprechend anpassen.

Zuletzt hier nochmal drei schnelle Beispiele aus aller Welt, das hw=crossing-Nodes dieser Art auch gängige Praxis in OSM bei separat gemappten Gehwegen sind (die ersten "unmarkierten" oder "uncontrolled" Querungsstellen an Kreuzungen, die mir jeweils in die Hände gekommen sind, auch wenn ich nicht im Einzelnen gerüft habe, ob da evtl. andere bauliche Merkmale vorliegen): osm.org/node/298373001 (Helsinki), osm.org/node/9680100473 (Moskau), osm.org/node/6769373148 (San Francisco)...

Wie du merkst, beschäftigt mich das Thema sehr, da (nicht nur) ich hier ein unheimlich großes Potential in detaillierten OSM-Daten sehe. Erst kürzlich hab ich von einem Projekt zur Schulwegsicherheit gehört, in dem auch OSM-Daten herangezogen wurden und genau solche "unmarkierten" Querungsstellen ausgewertet wurden. Fußgängernavigation/-sicherheit/Barrierefreiheit kommt ja zur Zeit fast an jeder Ecke auf bei Konferenzen, in Projekten etc. Das OSM-Potential kann sich aber nur dann entfalten, wenn solche Daten klar kategorisiert bzw. ausführlich genug für Interpretationen sind. (Ein Node ohne Tags wäre sozusagen "fast keine" Information ;) Vieles in diesem Bereich steckt in OSM noch eher in den Kinderschuhen, das zeigt sich z.B. an der oft mangelhaften Dokumentation (oder auch an dieser Diskussion). Auch deshalb ist der oben verlinkte berlin-spezifische Leitfaden entstanden, auch als Diskussionsgrundlage oder Vorlage für Neumapper, die manchmal nur schwer vom simplen "Malen" von Gehwegen abzuhalten sind ;)

Vielleicht kannst du ja jetzt nachvollziehen, warum "hw=crossing" an diesen Punkten einen Mehrwert hat - bzw. haben könnte(!), wenn besser/spezifischer gemappt?

P.S. ich werde die Gelegenheit natürlich nutzen, die Daten zu verbessern, insbesondere die Bordsteine an die tatsächliche Lage anzupassen, Subtags ergänzen und Fehler korrigieren.

Hallo Tom,
du hast hier viele crossing- und kerb-Nodes gelöscht, die aber durchaus ihre Berechtigung haben. Der User hat hier zwar im Zusammenhang mit dem separaten Mappen von Gehwegen handwerklich grob gearbeitet (insbesondere nur wenige Subtags wie "crossing=unmarked", "kerb=lowered" etc. verwendet) und in Einzelfällen Fehler gemacht (z.B. ist bei osm.org/node/3118827216 keine Querungsmöglichkeit, nebenan bei osm.org/node/3118827215 allerdings schon, was du nun "falsch" getaggt hast). Das sind aber Dinge, die sich ergänzen und vervollständigen lassen (was insbesondere rund um Neukölln auch kontinuierlich passiert) und die Daten nicht "falsch" machen. Im Gegenteil hast du insbesondere durch die Löschung der kerbs (in Einzelfällen bereits mit "kerb=lowered" ausgestattet) sogar einen qualitativen Informationsverlust herbeigeführt. "highway=crossing" an den Schnittstellen zwischen Gehwegen und Straßenlinien ist außerdem verbreitete Praxis beim separaten Mappen von Gehwegen, auch an Kreuzungsbereichen ohne besondere bauliche Merkmale der Querungsstellen.

Ich würde die (alten) Daten daher eher als "Vorleistung" verstehen, die sich verbessern lässt, aber nicht falsch ist, und sie daher wieder herstellen.

liebe Grüße
Alex

Hallo Video2005,

danke für die Ergänzung der Fahrradständer unter der Autobahnbrücke! "level=1" ist irreführend bzw. würde eher erwarten lassen, dass sich die Fahrradständer auf der Autobahn befinden :)
Ich hab den Wert mal auf "0" geändert, was eher dem Erdgeschoss-/Erdbodenniveau entsprechen würde.
Allerdings wird "level" eigentlich nur im Zusammenhang mit Gebäuden genutzt, also um eine Lage in einem bestimmten Stockwerk eines Bauwerks zu bestimmen. Bei Dingen rund um Straßen reicht die Verwendung von "layer" aus, um auszudrücken, dass etwas über oder unter etwas anderem ist. Hier in diesem Fall trägt die Autobahnbrücke und die darüber laufenden Autobahnabschnitte ein "layer=1". Es wäre also auch ohne level- und layer-Tags klar, dass sich die Autobahn über allen anderen Objekten befindet.