Hallo, herzlich Willkommen bei OSM und vielen Dank für diese Änderung direkt aus "erster Hand"!

Eine Nachfrage zu den neuen Einbahnstraßen in der Modersohn- bzw. Gärtnerstraße: Ist der Radverkehr von den Einbahnstraßenregelungen ausgenommen, also die Einbahnstraßen für den Radverkehr in beide Richtungen freigegeben? Falls ja, sollten wir "oneway:bicycle=yes" (vgl. osm.wiki/Key:oneway:bicycle) an den Straßen ergänzen, damit bspw. Routinganwendungen für Radfahrende hier weiterhin in beide Richtungen funktionieren.

Beste Grüße
Alex

Hallo momabebra, schönes Micromapping des Parks hier vor der Schwimmhalle an der Zingster Straße! Allerdings hast du die Parkfläche der ausgewiesenen geschützten Grünanlage (leisure=park + protection_title=Geschützte Grünanlage) dabei gelöscht. War das nur ein Versehen oder habe ich etwas übersehen?

lg, Alex

Hallo pingpongo, willkommen (zurück) bei OSM und vielen Dank für deine vielen sehr guten Änderungen in den letzten Tagen hier in der Gegend!

Falls du mal Fragen oder Unterstützungsbedarf hast, melde dich gerne (z.B. bei mir oder auf einem der Berliner OSM-Kanäle). Ansonsten: Happy Mapping! :)

Beste Grüße
Alex

P.S. Ich habe ein paar kleine Korrekturen an Änderungen von dir aus der letzten Zeit vorgenommen – nichts wildes, aber bei Bedarf kann ich dir auch Details dazu schreiben.

Hallo ihr beiden, bitte beachtet, dass solche crossing-Nodes (unmarked oder uncontrolled) gängige Praxis beim Mappen separater Gehwege ist – nicht nur in Berlin, sondern weltweit. Auch das Wiki weist darauf hin: "In areas where sidewalks are mapped as separate geometries, it is commonly seen that every node at which a sidewalk crosses a road, an unmarked crossing is added. So this is something to look out for as data consumer, crossings tagged like this often do not have any recognizable structural measure that deserve to be called a dedicated crossing." (osm.wiki/Tag:crossing%3Dunmarked).

Ich kann nur davon abraten, sie zu entfernen – sie würden früher oder später ohnehin wieder ergänzt werden. Wenn Navis davor warnen, dann werten sie die Daten unzureichend aus.

lg, Alex

Hello Squ_are,

you made some changes on memorials today where you changed "wikimedia_commons" to "subject:wikimedia_commons". To me, these changes look wrong, as the linked Wikimedia resources lead directly to photos of the memorials themselves and therefore “wikimedia_commons” is the correct tag. I will therefore revert the changes soon. Or what are these changes about? (When making changes, please make sure that you don't just blindly work through any lists, but also check each individual change to see whether it really makes sense).

Best,
Alex

Hallo LordMadsen,

du hast in einige Hausnummern mit Buchstaben Leerzeichen eingefügt. Ich würde dich bitten, diese Änderungen wieder rückgängig zu machen, da als übliche Notation in OSM die Variante ohne Leerzeichen verwendet wird. (Beispielhaft gibt es in OSM 250.000 mal die Variante "1a/1A", aber nur 8.000 mal "1 a/1 A".)

Beste Grüße
Alex

Hello MapSpot,

you changed "parking=level" to "parking=rooftop" here. I reverted this change since there is no rooftop parking, just a single parking level in the bottom of the building. We have no fitting documented parking tag for such situations, thats why I used "parking=level" in this and some other cases.

Best, Alex

Hallo Jonas,

danke für deine ausführliche Rückmeldung. Ich kann sie aber nicht nachvollziehen bzw. finde, dass sich an diesem Changeset sogar gut der entscheidende Vorteil der Lifecycle-Prefixes bzw. der Nachteil solcher Formen von "Datenhygiene" veranschaulichen lässt.

Nehmen wir den nördlichen der gelöschten Bäume am Mariendorfer Weg als Beispiel (osm.org/node/3411779330): Bei dem Versuch, mir die Stelle genauer anzusehen, musste ich feststellen, dass der Baum erst vor zwei Jahren gefällt wurde. Und obwohl wir in Berlin eine extrem aktive Mapillary-Szene haben mit ca. einem halben Dutzend Leuten, die permanent Bilder aufnehmen – was es sicherlich nur an wenigen anderen Orten der Welt überhaupt so gibt – gibt es an dieser Stelle kein Bild _ohne_ diesen Baum. Auch auf allen Luftbildern, die älter als aus dem letzten Jahr sind, ist der Baum also noch zu sehen. (Hier ist er, wenn ich richtig sehe: https://www.mapillary.com/app/?lat=52.4644058&lng=13.4313526&z=18.419376898265654&panos=true&focus=photo&x=0.5689713146724832&y=0.4626824991933902&zoom=0.06021122375082248&pKey=504304587920293)

Daraus ergibt sich das Problem, dass es nicht unwahrscheinlich ist, dass bald jemand daherkommt und den Baum wieder einträgt, weil er sowohl auf "relativ" aktuellen Luftbildern als auch Straßenfotos zu sehen ist. Das ist genau der Sinn der Lifecycle-Prefixes, dass so etwas nicht passieren kann.

Und ja, wir haben in Berlin und insbesondere hier in Neukölln einige Mapper, die regelmäßig solche Details mappen (vielleicht kennst du die Straßenraumkarte Neukölln, auf der in einigen Gebieten quasi jeder Stromkasten und Gullideckel zu sehen ist: https://strassenraumkarte.osm-berlin.org/?map=micromap#19/52.46448/13.43160). In Neukölln sind wir z.B. mindestens zwei Mapper, die jeden Baumstumpf erfassen, sobald ihnen ein gefällter Baum auffällt (siehe die auffällige Häufung von hunderten Baumstümpfen hier in der Gegend: https://overpass-turbo.eu/s/1PiF).

An dieser Stelle hier ist mir auch nichts von einer "wirklich endgültigen" Entfernung der Baumscheibe o.ä. bekannt. Wahrscheinlich klassisch ein Sturmschaden und wenn mal wieder Geld da ist kommt ein neuer Baum hin. (Ich gehe mal davon aus, dass du aus der Ferne eher keine anderen Informationen hast?)

Tut mir leid, dass ich da so allergisch reagiere, aber es kommt leider häufiger vor, dass gut gemeinte "Datenhygiene" aus der Ferne Probleme verursacht, wenn man – so wie wir hier – sehr detaillierte und gut gepflegte Daten mit einer aktiven Community dahinter hat, die die Daten auch auf vielfältige Weise nutzt und lieber selbst entscheidet, was für sie sinnvoll ist und was nicht.

lg, Alex

Hallo PizzaTreeIsland, warum hast du die entfernten Bäume denn gelöscht? Es ist nicht unüblich, dass auf den Baumscheiben irgendwann neue Bäume gepflanzt werden, zudem können wir mit diesen Daten einen Überblick behalten, wo in der Vergangenheit Bäume gefällt bzw. entfernt wurden. Ich habe die Daten daher wieder hergestellt.

Da du diese Änderungen offenbar auch an anderer Stelle gemacht hast, möchte ich dir außerdem mit auf den Weg geben, dass solche massenhaften Remote-Änderungen mMn alles andere als hilfreich sind... Oder welchen Mehrwert siehst du darin? Lokale Mapper sollten schon selbst entscheiden, wann sie solche Daten nicht mehr benötigen, denn das kann z.B. auch von lokalen Luftbild-Zyklen abhängen (ab wann kann man z.B. Bäume nicht mehr auf Luftbildern erkennen), die dir als Remote-Mapper ja höchstwahrscheinlich unbekannt sind.

lg, Alex

Hallo rti, danke für deine Ergänzung hier an der Graefestraße in Berlin Kreuzberg! Ich musste sie allerdings zurücksetzen, da wir in OSM die Anzahl der Fahrspuren üblicherweise nur erfassen, wenn es markierte Fahrspuren gibt. Anderenfalls ergibt sich die Beschaffenheit der Fahrbahn aus Angaben zur Fahrtrichtung, Breite etc., was hier alles korrekt erfasst ist.

Beste Grüße
Alex

Teils zurückgesetzt, siehe auch osm.org/changeset/154603363

Habe die Änderungen überwiegend zurückgesetzt.

Hallo momabebra, diese Änderung musste ich teils zurücksetzen, denn einmal mehr scheinst du hier unnötigerweise eine Einfahrt gelöscht zu haben, die sicherlich noch existiert.
lg, Alex

Hallo momabebra, wieso hast du hier über zwei Drittel aller Tags vom Radweg an der Rudower Chaussee gelöscht, darunter Breiten-, Oberflächen- und Verkehrszeichenangaben? Nicht nur, dass das wichtige Angaben für eine ganze Reihe von Anwendungen sind – es gibt eine Reihe von Mappern die solche Details mühsam erfassen und einfach nur frustriert sind von deine teils rücksichtslosen Änderungen dieser Art. Jemand, der so viele Änderungen wie du durchführt (darunter meistens auch sehr wertvolle) muss hier sorgfältiger vorgehen.
lg, Alex

Hallo momabebra, wie schon mehrmals hingewiesen, haben Bordsteinkanten in OSM ein Richtung – die rechte Seite schaut "nach unten". Das ist in JOSM normalerweise auch am Linienstil erkennbar (die Dreiecke müssen zur Fahrbahn schauen). Du erzeugst leider weiterhin ständig Daten mit falscher Ausrichtung... lg, Alex

@Pisto81: What unconnected nodes are you meaning? Can you give an example, where there is a problem with this changeset?

Hallo grafter, ich habe das Thema nochmal auf die Tagesordnung unseres nächsten Berliner OSM-Verkehrswende-Communitytreffens gesetzt. Wir haben hier eine aktive Gruppe (mich eingeschlossen), die solche Daten auch pflegen würde und sie nutzt (siehe z.B. https://parkraum.osm-verkehrswende.org/project-prototype-neukoelln/?map=parkingmap#15/52.4869/13.4297 - die Daten zu Parkzonen werden dort bisher aber noch aus dem Berliner Geoportal bezogen - könnte man dann perspektivisch auf "pure OSM" umstellen).

Eine Relation aller Parkplätze und Parkscheinautomaten würde ich eher als überflüssig erachten, da diese Features alle über ein gemeinsames "zone"-Attribut (das hier auch schon gesetzt ist) gruppiert werden können.

lg, Alex

P.S. Wenn du "is_sidepath=yes" tolerieren kannst, dann solltest du auch "is_sidepath=no" tolerieren, denn für Datenauswerter gibt es nichts schlimmeres als einen "unbestimmten" Zustand, bei dem man nicht weiß, ob er einfach nur noch nicht erhoben wurde, oder ob er einer evtl. vorhandenen Standardannahme entspricht...

Hallo IngoWo, das "is_sidepath"-Tagging wurde _genau deshalb_ entwickelt, weil es für Datenanwender nicht trivial ist, diese Information aus der Geometrie abzuleiten. Obwohl das Tagging noch nicht sehr weit verbreitet ist (da der "Entwicklungsprozess" noch nicht abgeschlossen ist), gibt es bereits verschiedene Anwendungen, die es benutzen (siehe osm.wiki/Proposal:Key:is_sidepath#By_applications). Ich selbst habe erst bei der letzten FOSSGIS ein Projekt vorgestellt, bei dem es um die Evaluierung der Radverkehrsqualität ist, wobei die "Straßenbegleitung" ein wichtiges Merkmal ist – und deren Ermittlung (ohne sidepath-Schema) derzeit etwa 95% der Rechenzeit verschlingt, um am Ende ein ungenaues, oft fehlerhaftes Ergebnis zu bringen.

Aber ganz unabhängig davon ist es keine gute Idee, Tags zu löschen, die du für "überflüssig" empfindest. Denn OSM ist ein Community-Projekt und was nützlich ist und was nicht, darf jeder für sich selbst entscheiden. Wenn das zu "vielen" Tags an einem Objekt führt, dann musst du damit leben.

(Das von dir beschriebene Phänomen einer Flut von access-Tags bleibt mMn davon unberührt, denn hier lässt sich tatsächlich häufig durch Verwendung der jeweiligen höheren access-Klassen "kürzen". Der Unterschied hierbei ist, dass kein Informationsverlust entsteht.)

Es tut mir übrigens leid, dass es in Bremerhaven nicht so viele aktive Mapper gibt. Ich drücke dir die Daumen, dass sich das vielleicht noch ändert!

lg, Alex

#bordsteinkantenlinienrichtung korrigiert, siehe https://resultmaps.neis-one.org/osm-discussion-comments?uid=9508237