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 (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 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

Hallo momabebra, du machst hier gutes Mapping, aber erneut musste ich viele deine Änderungen nachbearbeiten, da du systematisch viele Bordsteinkanten in die falsche Richtung zeichnest. Leider ist es nicht möglich, dich zu erreichen (vgl. die Historie deiner CS-Diskussionen: https://resultmaps.neis-one.org/osm-discussion-comments?uid=9508237), daher sehe ich mich gezwungen, noch einmal die DWG einzuschalten, bis du erreichbar bist, um dich auf solche systematischen Fehler aufmerksam zu machen.
lg, Alex

Hallo momabebra, wie schon öfter angemerkt hast du auch hier wieder Bordsteinkanten in falscher Richtung verwendet. Aber leider liest du ja keine CS-Kommentare...
lg, Alex

Hallo momabebra, wie schon öfter angemerkt hast du auch hier wieder Bordsteinkanten in falscher Richtung verwendet. Aber leider liest du ja keine CS-Kommentare...
lg, Alex

Hallo Bernd,

danke für deine ausführliche Rückmeldung. Vielleicht kann ich noch ein paar Punkte aufklären:

> warum sollte der Renderer auf der centerline darstellen, dass der Radweg separat gemappt ist

cycleway*=separate lässt sich z.B. zur Generalisierung nutzen, insbesondere, da die Straßen ihre begleitenden Wege oft überdecken. "separate" wird dabei wie "track" behandelt. "Die beiden auf osm.org" tun das vielleicht nicht, aber anderen steht diese Option offen und ich habs z.B. schon selbst für Radkarten so verwendet.

> ich habe auch schon diverse falsch getaggte Wege mit *:both gesehen

Das mag sein, sehe ich auch regelmäßig. "Falsche" Daten (die sich korrigieren lassen, wenn es einem auffällt) sollte man aber mMn nicht mit "ungenauen" Daten vergleichen (die sich nicht korrigieren lassen, wenn man das Schema dafür nicht verwendet).

> "cycleway:left=no"+"https://wiki.openstreetmap.org/wiki/Tag:cycleway:right=separate" bei separatem Mehrrichtungsradweg sehe ich hingegen sogar kritischer weil irreführend wenn nicht gar falsch, da es im ersten Schritt suggeriert, dass ich left auf der Straße fahren kann/muss/soll, da ja keine Radinfrastruktur für die Fahrtrichtung vorhanden ist.

Nein, dann interpretierst du die Daten falsch oder ungenau. "cycleway" gibt nicht an, wo du fahren darfst/sollst, sondern ist ein reines, richtungsabhängiges Attribut für Infrastruktur. Wo du fahren darfst/sollst, wird durch access-Tags angegeben. In diesem Fall ist durch "bicycle=use_sidepath" klar erkennbar, dass das Routing in beiden Fahrtrichtung über eine Nebenlinie stattfinden soll. Umliegende Geometrien müssen dafür nicht einbezogen werden (Router setzen einfach nur die Penalty für das Segment hoch oder schließen es sogar ganz aus).

Aber nichts für ungut, du scheinst ja zumindest die Intention für das Tagging nachvollziehen zu können.

lg, Alex

P.P.S. Ich sehe gerade, dass du sogar verschiedene Angaben wie "cycleway:left=no" und "cycleway:right=separate" zu einem "cycleway=separate" zusammengeführt hast. Das ist sehr ungünstig, da nun aus den Daten nicht mehr hervorgeht, auf welcher Seite sich der separate Weg befindet. Für verschiedenste Anwendungen, aber auch Renderer kann diese Information sehr nützlich sein.

lg, Alex