Hab Brücke und Laderampen wiederhergestellt! Kein Problem und sorry für meine erboste Reaktion ;)

Und die BSR-Laderampen - die haben zwar noch kein besonders gutes Schema, aber löschen ist auch doof -.- (Ich gehe davon aus, dass sie nicht verschwunden sind?)

Reverted.

Warum bekommt denn jedes Wegesegment bei dir ein eigenes Changeset? Kannst du z.B. diesen Fluss nicht "am Stück" hochladen?

liebe Grüße
Alex

---

Why does each path segment get its own changeset? Can't you upload this river, for example, "in one piece"?

Best, Alex

Nach deiner Beschreibung klingt es tatsächlich sehr nach "good". "excellent" ist außergewöhnlich gut, ohne Risse und sehr glatter Asphalt zum perfekten Inline skaten. Würde ich nicht inflationär verwenden. "intermediate" ist bereits mit einem leichten Geschwindigkeitsverlust verbunden. Viele Asphaltstraßen sind einfach nur "good".

Ansonsten kann ich Stefan nur zustimmen: "surface" und "smoothness" gern ergänzen, da das zunehmend relevante Routing-Informationen werden.

Hallo Fabian und willkommen bei OSM!
Du hast eine sehr schöne Schulhofgestaltung am OSZ Lise-Meitner gemappt! :) Das alte Gebäude scheint inzwischen abgerissen worden zu sein, richtig? Du hast es gelöscht - das ist nicht so schlimm, aber ich habe es wiederhergestellt und als "abgerissen" gekennzeichnet, damit sich niemand wundert, warum dort auf Luftbildern ein Gebäude steht, aber in der Realität (vermutlich) nicht mehr.
lg, Alex

Ach ja, wurde es. Hab es auf neueren Bildern von der Seite gesehen: https://www.mapillary.com/app/?lat=52.5086421&lng=13.466245799971944&z=18.909379867793096&pKey=161232019845926&focus=photo&x=0.054062666369509016&y=0.6036391284718807&zoom=0.0387386684618515&dateFrom=2022-01-01

Du hast hier im Sommer mal das Gehwegparken weggenommen - wurde das aufgehoben? Kann dazu nichts online finden. Bei Mapillary im letzten Jahr ist hier noch Gehwegparken angeordnet.

P.S. Habe gerade noch "maxspeed" entfernt, da das ja nicht mehr aktuell ist und bei dieser Gelegenheit "surface=asphalt" erstmal wieder ergänzt.

Hallo P1Madsen, danke für die Aktualisierung des verkehrsberuhigten Bereichs in der Weichselstraße! Du hast dabei die "surface"-Oberflächeninformation (asphalt) entfernt - aber daran hat sich vermutlich nichts geändert? Was das ein Versehen und kann wieder rein?
lg, Alex

Hallo Nico, das bicycle=no auf den Gehwegen neben der Fahrradstraße in der Weserstraße ist nicht notwendig, da Gehwege ohnehin nicht für Fahrräder freigegeben sind. "highway=footway" impliziert sozusagen "bicycle=no".

lg, Alex

Hallo Nawarbr, du hast hier eine boundary zu einer Fährlinie umgewandelt, was falsch aussieht (die Fähre ist noch nichtmal im Wasser). Kannst du das korrigieren oder benötigst du Hilfe dabei?

lg, Alex

---

Hey Nawarbr, you changed a boundary section to a ferry line here, but this looks wrong (ferry isn't even in the water). Can you fix this or do you need help?

Hey, sieht so aus, als wäre ein neuer Teil des Wohnparks freigegeben worden? ;) Hier gibt es übrigens eine Notiz, um den Baufortschritt zu dokumentieren: note/2088941

lg, Alex

Hey, was hast du denn hier für Geheiminformationen gespeichert :)

P.S. "cobblestone" würde auch recht schnell wieder verschwinden, da StreetComplete in diesen Fällen die surface-Quest stellt. Unbedarfte User wählen dann manchmal "paving_stones" aus, sodass im schlimmsten Fall sogar mehr kaputt geht.

Die Eignung/Befahrbarkeit müssen wir mit "smoothness" ausdrücken. "Normales" (also schlechtes) Berliner Kopfsteinpflaster ist meistens "smoothness=bad".

Unbehauenes Kopfsteinpflaster ("unhewn_cobblestone") gibt es in Berlin nicht mehr oder höchstens vereinzelt in den Außenbezirken. Das passt hier definitiv nicht. Und "cobblestone" ist wie gesagt nur der veraltete Oberbegriff für beides. "Behauen" und "geglättet" heißt mehr oder weniger, dass es keine Natursteine sind, sondern diese künstlich bearbeitet, also geglättet, sind. "Glatt" ist die Straße deshalb leider nicht ;)

Zur Verwendung der surface- und smoothness-Tags gibt es hier eine gute Tabelle mit vielen Beispielbildern, die dazu beitragen soll, die Kategorien in OSM einheitlich zu verwenden (einige davon auch aus Berlin): smoothness=*/Gallery

Groß- und Kleinsteinpflaster können wir in OSM also bisher höchstens über den smoothness-Wert unterscheiden, da das Kleinsteinpflaster meistens besser befahrbar ist. Ich hab schon seit längerem vor, ein Proposal für einen Subtag für "sett" zu entwickeln, damit die verschiedenen Pflastertypen auch direkt abgebildet werden können, aber ich komme derzeit nicht dazu...

Ich kann dafür osm.wiki/Wetter_Baum empfehlen :)

-> genus=Malus sowie leaf_* ergänzt.

Hallo mardiz, du hast hier surface=sett durch "cobblestone" ersetzt - dieser Wert wird aber in OSM nicht mehr empfohlen, da er lediglich eine "Oberkategorie" für verschiedene Formen von Kopfsteinpflaster darstellt. "sett" ist die korrekte Bezeichnung für künstlich behauenes Kopfsteinpflaster (in Abgrenzung zu "natürlichem, rundem, unbehauenem" Kopfsteinpflaster) und ist daher an den meisten Stellen in Berlin die korrekte Bezeichnung. So auch hier. Habe daher die Änderungen wieder zurückgesetzt (z.B. deine Korrektur in der Waldstraße von "paving_stones" zu "sett" übernommen).

lg, Alex

P.S: Das mit der Transportleitung wäre besser in einem separaten Tag aufgehoben, den man dann auch einfacher auswerten/danach suchen kann. Wie wäre es z.B. mit "fire_hydrant:water_source" (https://taginfo.openstreetmap.org/keys/fire_hydrant%3Awater_source#values - passt das hier häufig verwendete "main"?) oder im Zweifelsfall einfach einem "fire_hydrant:note=Transportleitung"?

lg, Alex

Bitte seid doch beide etwas verständnisvoller füreinander. Das ist doch jetzt hier kein Konflikt, um in einen ungemütlichen Umgangston zu verfallen.

Ich habe bisher noch nicht den Eindruck gewonnen, dass es sich um einen "schlechten" Import von Thorben handelt. Das ref-Problem lässt sich lösen – ich bin hier ganz bei Roger Wilco: In OSM erfassen wir, was auf dem Schild steht, auch wenn es intern anders bezeichnet wird. Denn sonst kommt irgendwann ein anderer Hydrantenmapper vorbei und schon sind die Daten inkonsistent. Das wäre sicher für alle Seiten ungünstig. Wenn die Zusammensetzung der Nummer für die Verwendung bei der Feuerwehr relevant ist, könnte man über einen gesonderten ref-Tag mit Namespace (osm.wiki/Namespace) nachdenken. Aber deshalb muss man ja nicht gleich ungehalten werden. Auch Fehler können durchaus passieren (auch wenn ich selbst nicht einschätzen kann, wie problematisch das hier ist - scheint mir bisher im Rahmen des üblichen.)

Es wäre aber tatsächlich sehr schön gewesen, den Import vorher auf einem passenden Kanal anzukündigen, z.B. einer lokalen Mailingliste, dem OSM-Forum oder ähnlichem. Dabei hätte man solche Dinge wie das mit der "ref" schon im Vorhinein klären können. Transparenz über die Datenquelle und die eigenen Möglichkeiten, die Daten verifizieren zu können, hätten sich dabei auch geklärt. Ich habe auf jeden Fall auch den Eindruck, dass du (Thorben) nicht sehr transparent darüber kommunizierst, was - wie bereits geschrieben - in einem Community-Projekt sehr ungünstig ist. Vielleicht findest du ja einen Weg, hier zur weiteren Verbesserung beizutragen und ähnliche Ergänzungen zukünftig anzukündigen.