Hallo unni-geo,

danke für deine vielen Abbiege- und Busspurattributergänzungen derzeit. Allerdings glaube ich, dass du bei temporären Busspuren ein wenig sinnvolles Schema verwendest.

Du hast hier lustigerweise ein Teilstück erwischt, dass ich erst kürzlich nach einer lokalen Diskussion als "Blaupause" für temporäres Busspurmapping erstellt hatte, bin mir aber auch noch nicht sicher, ob das so sinnvoll ist. Wollte dazu demnächst nochmal eine Community-Diskussion starten und ein "gutes" Vorgehen für temporäre Busspuren dann im Wiki dokumentieren, denn die derzeitige Dokumentation ist leider sehr ungenügend bzw. nicht vorhanden.

Ich habe deine Änderungen zumindest an diesem Teilstück hier noch einmal rückgängig gemacht, und zwar aus folgenden Überlegungen heraus:

- Normalerweise ist "psv:lanes" bzw. "psv:lanes:conditional" (z.B. "yes|yes|designated") nicht notwendig, da die deutlich einfachere Angabe "lanes:psv=1" bereits ausreicht, um diese Spurverteilung abzuleiten. Ähnlich wie bei Fahrradwegen ist die Grundannahme, dass sich der Sonderfahrstreifen auf der rechten Fahrbahnseite befindet (also die rechteste der vorhandenen Spuren ist). Nur, wenn die Busspur in Mittellage geführt wird, hat "psv:lanes" daher einen Mehrwert (ebenfalls wie bei Radwegen).

- Falls du dennoch "psv:lanes:conditional" verwendest, müssen vor und hinter das "@" auf jeden Fall zwei Leerzeichen.

- Bei der "temporären" Angabe, dass die Busspur nur zwischen 5 und 19 Uhr zur Verfügung steht, kann man sich streiten, ob dann der Zustand bei Nacht oder am Tag der Default/Vorgabewert sein sollte und die jeweils andere Angabe dann die conditional-Angabe. Ich tendiere eher dazu, den restriktiveren Wert (also hier: die kleinere Spurzahl) als Vorgabe zu verwenden, also auf dem Columbiadamm z.B. "lanes=2" + "lanes:conditional=3 @ (05:00-19:00)". Das entspricht hier außerdem der ausgeschilderten Zeitangabe. Aber man könnte natürlich auch argumentieren, den "meistens" oder "für die meisten Verkehrsteilnehmenden" gültigen Wert als Vorgabe zu verwenden, also "lanes=3" + "lanes:conditional=2 @ (19:00-05:00)". Ich könnte mit beidem gut leben. Da du hier aber gar keine conditional-Angabe machst, sondern nur die größere Spurzahl angibst, verschwindet diese Unterscheidung und ein Interpreter würde "immer" 3 Fahrspuren annehmen. Die zeitliche Beschränkung nur in einem "lanes:psv:conditional"-Attribut (bzw. bei dir "psv:lanes:conditional") zu verstecken, könnte zu wenig sein, je nach dem, wer und wie die Daten interpretiert werden.

Oder was meinst du? Insbesondere was die Verzichtbarkeit von "psv:lanes" angeht, würdest du mir da zustimmen? Vielleicht finde ich in den nächsten Tagen mal die Zeit, die oben erwähnte Diskussion im Community-Forum anzustoßen, dann können wir auch noch mehr Meinungen zusammenbringen. Und eine (meiner Meinung nach) längst überfällige Lücke in der OSM-Dokumentation schließen.

Beste Grüße
Alex

Ah ok! Ich hab mal ein "fixme" ergänzt, vielleicht triggert das bei jemandem da mal nachzusehen. Und das "Dr. med" auch entfernt, da das kein guter Name ist (ein Symbol bleibt in den meisten Karten ja dennoch erhalten).

Hallo Jens, bei der Bearbeitung des 0%-Spätis hast du glaub ich ausversehen bei diesem Arzt den Namen gelöscht, kann das sein? node/7073849640 (vorher "Dr. med. Jean Joseph Levy", jetzt nur noch "Dr. med.") ;)

lg, Alex

Hallo BER319,

kannst du mal hier schauen, ob die Änderung in deinem Sinne ist? note/3548487

Du hattest den Standort vor ein paar Monaten so gemappt und ich habe ihn gerade etwas angepasst wie in der Note beschrieben.

lg, Alex

Hallo,

die gelöschten Geometrien waren 3D-Gebäudeinformationen (Gebäudeteile mit u.a. Höhen-/Stockwerksinformationen, schwebende Gebäudeteile etc.), die zwar handwerklich nicht optimal gemappt sind und tatsächlich manchmal "nerven", wenn man "nur" das Gebäude selbst bearbeiten will, aber das ist kein Grund sie zu löschen. Jemand scheint sich hier vor einiger Zeit viel Mühe damit gemacht zu haben und für einige Anwendungszwecke sind diese Angaben sehr hilfreich. Ich habe sie daher wieder hergestellt.

Bitte achtet als BKG darauf, solche aus eurer Perspektive als "unwichtig" erscheinende Informationen nicht zu entfernen sondern nur die relevanten Geometrien (hier also: den Gebäudeumriss) zu bearbeiten. Im JOSM-Editor kann man beispielsweise mit Alt+Mausklick verschiedene übereinander liegende Geometrien "durchschalten" um zum eigentlichen Gebäudeumriss zu kommen.

Beste Grüße
Alex

Hallo JeromeMolnar, handelt es sich bei den Wegen hier nicht um Wege im Gelände der "Easy Lodges"? Falls ja, wäre "customers" dann doch richtig, da die Besucher der Lodges die Wege nutzen können.

lg, Alex

Hallo, du hast hier ziemlich viele Angaben gelöscht, die auf den ersten Blick nicht falsch aussehen: Toiletten für Rollis, Telefonkontakt und vor allem Gebäudedetails (Höhen/simple 3D etc.). Insbesondere hast du den building-Tag des Gebäudes (building=school) gelöscht, sodass dieses Gebäude nun kein Gebäude mehr ist.

Der Kern deiner Änderung ist offenbar der (korrekte, soweit ich sehe) Wechsel zu amenity=college. Hätte das nicht ausgereicht ohne die anderen Angaben zu löschen?

Ich würde also dafür plädieren, die Änderung zurückzunehmen und nur "amenity=college" zu ändern - es sei denn, ich habe etwas übersehen.

Nachtrag: Spontan drei Beispiele anderer Feuerwehren und wie sie ihr Vorgehen dokumentiert haben:

osm.wiki/Auracher_Gruppe_Hydranten_Import

osm.wiki/Friesland_Hydranten_Import

osm.wiki/Gangelt_Hydrantenimport

Hallo GamingFAIL, bei OSM freuen wir uns immer sehr, wenn solche Datensätze bereitgestellt werden, allerdings gibt es recht strenge "Richtlinien" zum Import solcher Daten, damit die OSM-Daten auf lange Sicht qualitativ hochwertig bleiben und möglichst konsistent bleiben (diese Richtlinien lassen sich grob als "lieber keine Daten als fehlerhafte Daten" übersetzen.) Siehe z.B. hier: osm.wiki/DE:Import/Guidelines - für einen Hydrantenimport muss man jetzt vielleicht nicht jeden einzelnen dort aufgeführten Punkt beachten, aber ein Blick darauf lohnt sich dennoch.

Bei den vorliegenden Hydranten sehe ich spontan einzelne Probleme, die sich aber bestimmt beheben lassen. Dazu gehört:

- Wenn du lokale Feuerwehrpläne nutzt, hast du offenbar Kontakte zur lokalen Feuerwehr oder bist selbst Mitglied? Es wäre gut, irgendwie zu dokumentieren, dass die vorhandenen Pläne von den Erstellern ausdrücklich für OSM zur Verwendung freigegeben werden. Du könntest beispielsweise eine Mail mit dem Hintergrund dieses Imports an die Berlin/Brandenburger Mailing-Liste schreiben (berlin@lists.openstreetmap.de bzw. https://lists.openstreetmap.de/mailman/listinfo/berlin).
- Es muss sichergestellt sein, dass die Daten quasi Fehlerfrei sind, also keine veralteten/falschen/nicht mehr vorhandenen Daten enthalten. Da die Feuerwehr die Hydranten regelmäßig begeht, ist das bei Hydranten zum Glück meistens gut möglich.
- Ich habe die Daten nur ganz flüchtig angesehen aber habe bereits "handwerkliche" Fehler entdeckt. So gibt es z.B. in dieser (node/10589654475) und dieser (node/10276718513) Gegend einige Hydranten doppelt. Hier wäre es gut, wenn du nacharbeitest und doppelte Standorte korrigierst. Dabei hilfreich kann dieses Tool sein: Eine Overpass-Abfrage, die nahe beieinander liegende (evtl. doppelt gemappte) Hydranten ausspuckt: https://overpass-turbo.eu/s/1qIG Bereits vorhandene Daten/Punkte sollten auf keinen Fall gelöscht werden bzw. erhalten bleiben (außer Daten, die nicht mehr aktuell sind - die dann natürlich aktualisieren).

Melde dich gern, wenn du Fragen dazu hast oder Unterstützung brauchst - ich persönlich fände es schade, wenn es daran scheitert und die Daten im schlimmsten Fall wieder zurückgesetzt werden müssten.

Beste Grüße
Alex

Hallo momabebra,
ich lasse mal zwei Hinweise hier, die mir in deinen Changesets immer wieder auffallen:
- Querungsstellen von Gehwegen über Straßen solltest du zusätzlich mit einem "footway=crossing" ausstatten (so wie du korrekt "footway=sidewalk" an den Gehwegen selbst benutzt)
- Bitte vermeide unbedingt "natural=grassland" und nutze stattdessen "landuse=grass". "grassland" ist ein Tag für natürliche (unbewirtschaftete) Graslandvegetation/-landschaft und kommt so in der Stadt nicht wirklich vor!

lg, Alex

Hallo msch,

Willkommen zurück bei OSM nach so langer Zeit ;)

Wurden die Durchfahrten südlich und nördlich des Chamissoplatz durch Poller gesperrt? So interpretiere ich deine Änderungen.

Es wäre besser, die Poller als Punkte auf den Straßensegmenten zu platzieren (etwa dort, wo die Poller sind) und nicht ein ganzes Segment mit der Poller-Eigenschaft zu versehen (das ist für viele Anwendungen schwer zu interpretieren - habe es daher erstmal rückgängig gemacht).

Falls du ein Foto/Fotos von vor Ort hast, kannst du sie auch gern teilen, dann könnten wir gemeinsam schauen, wie es sich am besten abbilden lässt. (Könntest du z.B. über einen Bild-Uploader teilen, oder als Notiz mit der OSM-App "StreetComplete" an dieser Stelle hinterlassen oder auch gern einfach mir per Mail schicken: "alex@osm-berlin.org".) Vermutlich können wir die gesamten Straßensegmente nördlich und südlich des Platzes als für den Autoverkehr gesperrt eintragen? Vielleicht sogar als Fußgängerzone?

Kann auch die Tage dort mal vorbeifahren, falls das mit Fotos zu aufwendig für dich ist.

lg, Alex

Hallo SvenML, ich bin ganz bei dir: Diesen Asphaltstreifen sollte man nicht als "Radweg" bezeichnen und auch nicht als solchen nutzen. Allerdings ist er baulich als solcher vorhanden (durch die baulichen "Einfahrten" an den Enden auch als solcher erkennbar), nach welchen völlig veralteten Standards auch immer er vor langer Zeit mal angelegt wurde.

In der Berliner OSM-Community sind wir seit einiger Zeit dabei, den Ausbauzustand von Radwegen in Berlin systematisch zu erfassen, um insbesondere auch "schlechte" Radwege als solche identifizieren zu können. Da sind solche Informationen wie zu diesem Streifen hier recht hilfreich.

Daher hab ich den Radweg wieder hergestellt.

Um Routing über solche Wege zu verhindern bzw. ihre Qualität beurteilen zu können, können wir vielfältige physische Angaben (Breite, Oberflächenbeschaffenheit/-qualität, Pufferbreiten etc.) detailliert erfassen - das war hier bereits der Fall. Ich habe nun noch "bicycle=discouraged" als "Empfehlung zur Vermeidung" ergänzt. Mit diesen Angaben können Router (theoretisch, in der Praxis nicht immer) den Weg vermeiden bzw. feststellen, dass die Nutzung der Straße attraktiver ist.

two minor comments (just details :)

It's better to use two different nodes for a street lamp with a waste basket attached to it: One for the lamp post and one for the waste basket next to the street lamp. If you tag "support=street_lamp" on the waste basket, it will be clear that they belong together. Otherwise, with detailed information such as height, colour, material, etc., it is not clear to which object this attributes refer.

Also, you don't have to tag "foot=no" on a cycleway, as this is already implied by "highway=cycleway".

Both are no mistakes, just little "style tips", as you seem to have a talent for good mapping anyway :)

Best, Alex

(ich hoffe also, dass man das Issue in einem Jahr nochmal aufmachen kann, wenn die Zahlen entsprechend gestiegen sind... Bei "street_side" hat es ja damals auch ne Weile gedauert.)

Hallo geozeisig,

"parking=on_kerb" war kürzlich Teil des Street Parking Proposals, um die beiden Varianten des Straßenparken-Mappings (Straßenlinie vs. separate Geometrie) miteinander zu synchronisieren. Denn beim Mappen an der Straßenlinie gibt es "on_kerb"-Parking bereits seit langem. So wie "parking=lane" ist es ein Value, der sich (meiner Meinung nach) nicht für den Regelfall anbietet, sondern z.B. wie hier eher für "fragmentierte" Flächen, die man nicht gut/genau genug an der Straßenlinie abbilden kann.

Siehe osm.wiki/Proposed_features/street_parking_revision.

Was die Symbole an den Parkplätzen angeht: Ich habe schon versucht, ein angepasstes Rendering wie bei "street_side" zu erwirken, aber derzeit noch erfolglos, da der Tag erst einen Monat alt ist und daher noch kaum in Verwendung (https://github.com/gravitystorm/openstreetmap-carto/issues/4754).

Hab mal "barrier=parking_lane" aus den "parked_cars" gemacht - das ist der Wert, der sonst benutzt wird... Wobei das irgendwie alles semantisch nur so halb passt...

Hey momabebra, kleiner Hinweis (weiß nicht, ob du es vielleicht nur vergessen hast): Den Wegen über die Straße solltest du zusätzlich zu "highway=footway" noch "footway=crossing" geben.

Siehe auch osm.wiki/Berlin/Verkehrswende/Gehwege.

lg, Alex

Hallo karaga, du hast nun schon mehrfach Änderungen von User:Mapillox gelöscht, die vielleicht nicht immer in dieser Form sinnvoll waren, aber bist du denn auch schonmal mit ihm in Kontakt getreten, was es mit diesen Änderungen auf sich hat?

Hallo Stefan, vielen Dank für deine vielen Beiträge zu OSM in letzter Zeit! Eine Anmerkung zu dieser Änderung: In der Teetzlebener Straße in Altentreptow (way/23653989) hast du mit StreetComplete die Option "Radweg" ergänzt, allerdings war hier der Radweg bereits als separate Linie in OSM enthalten.

Vermutlich ist das in StreetComplete nicht immer gut zu erkennen (und es ist auf jeden Fall auch kein Weltuntergang ;), aber ich wollte dich trotzdem darauf hinweisen.

Beste Grüße und Danke für deine Beiträge!
Alex

Hallo geozeisig, ich hatte hier an der in Bau befindlichen Gedenkstätte zum Friedhofslager bewusst "monument" statt "memorial" gewählt, da es sich um eine recht große, begehbare Fläche handeln wird, die insgesamt den Gedenkort bilden wird. Laut Wiki sind die Größe und Begehbarkeit zentrale Kriterien, die für "monument" sprechen. Was spricht deiner Meinung nach eher für "memorial"?

Für optische Eindrücke (leider noch nicht fertiggestellt) siehe auch https://kkbs.de/blog/112054/kirchliche-gedenkstatte-zur-ns-zwangsarbeit-fur-die-kirche-berlin-neukolln-fast-fertig sowie https://commons.wikimedia.org/wiki/File:Gedenkst%C3%A4tte%20Friedhofslager%20Berlin-Neuk%C3%B6lln%20Baustelle%20November%202022.jpg.