Ah super. Das sieht so aus, als könnten die früheren Parkbuchten dann mit einer neuen Geometrie z.B. als Communitygarten oder ähnliches getaggt werde, wenn es soweit ist. Die Wohngebietsgrenze könnte dann auch vor zur Fahrbahngrenze verlegt werden. Kann ich auch gern machen, aber würde tendenziell noch warten, bis da mehr ist als nur Erde.

Vielleicht kannst du ja sogar ein Foto machen. Was bedeutet denn, das dort nun Erde ist? Vielleicht soll es ein Blumenbeet o.ä. werden?

Hallo mandavi, du wolltest hier eine Parktasche entfernen, hast aber dabei unbeabsichtigt das Wohngebiet/den Wohnblock entfernt. Daher musste ich die Änderung zurücksetzen.

Zur Info: In OSM ist hier keine Parkbucht mehr vorhanden – die sichtbare Einbuchtung neben der Eisenbahnstraße entspricht lediglich dem Bordsteinverlauf. Oder wurde hier baulich etwas verändert? Was befindet sich denn in dem Bereich der früheren Parkbucht?

@Sebastian Grönlund: Willkommen bei OSM! Du hast hier einige Änderungen vorgenommen, die wahrscheinlich nicht beabsichtigt waren, z.B. Gebäude gelöscht und Objekte verschoben. Wenn du Hilfe oder Unterstützung bei deinen ersten Schritten in OSM benötigst, schreib mich gerne an oder andere aktive Mapper aus der Gegend. Happy Mapping!
---
Welcome to OSM! You have made some changes here that were probably not intended, e.g. deleted buildings and moved objects. If you need help or assistance with your first steps in OSM, feel free to write to me or other active mappers in the area. Happy Mapping!

---

@pitscheplatsch: Thanks, I've reverted most of the changes because apparently some things were accidentally deleted or moved.

Hallo mxmln_bln,

danke für deine Ergänzungen an Parkstreifen! Ein Hinweis dazu: Es ist im Allgemeinen nicht nötig und sinnvoll, alle Parkstreifen in OSM separat als Fläche zu erfassen – dafür gibt es das "Street Parking"-Schema, das auch hier in der Gegend bereits an den Straßen erfasst ist. Kennst du das schon? osm.wiki/DE:Street_parking

Die hier von dir ergänzten Parkflächen sind jetzt sozusagen "doppelt" vorhanden, da die Informationen bereits an der Straßenlinie stehen. Eine Möglichkeit, das zu vermeiden, ist, "parking:both/left/right=separate" an der Straßenlinie zu hinterlegen. Die separate Erfassung von Parkstreifen ist aber eher für "spezielle" Situationen gedacht, wie kleinteilige Parkbuchten, regelmäßige Parkstreifenwechsel oder wenigstens für markierte Parkstände. Wenn ich richtig sehe, sind diese hier nicht markiert, also einfach nur Fahrbahnbereiche, die zum Parken genutzt werden.

Falls du dich für das Thema Parken interessierst: Kennst du schon die Neuköllner Parkraumkarte bzw. das OSM-Parkraumprojekt? https://parkraum.osm-verkehrswende.org/project-prototype-neukoelln/?map=parkingmap#18/52.48208/13.42994

liebe Grüße
Alex

(P.S. hab ich hier ergänzt)

Am besten dann gleich cycleway:both=no ergänzen ;)

Hallo delineatorix, danke für den neuen Laden, den du hier in der ehemaligen Apotheke eingetragen hast. Du hast "level=1" dran geschrieben, aber die Apotheke war im Erdgeschoss. Müsste also "level=0" sein, oder habe ich etwas übersehen?

Habe den Laden außerdem mit dem Punkt der früheren Apotheke zusammengeführt, um die "Geschichte" der Ladenräume zu erhalten und damit nicht zwei Punkte, die sich auf den gleichen Ort beziehen, existieren.

beste Grüße
Alex

Jein – gemäß des (neuen) Street Parking-Schemas ist beides möglich und synonym – je nach dem, wie explizit man die ausgeschilderte Regelung erfassen will (osm.wiki/Street_parking#No_parking,_no_stopping,_and_no_standing).

Allerdings würde die restriction-Variante letztendlich auch als access=no + emergency=designated interpretiert werden oder impliziert das sogar – von daher hast du recht, dass access=yes zumindest unglücklich ist. Hab es angepasst.

Hallo synchron, mir ist hier aufgefallen, dass du die separaten Parkflächen/Parkbuchten bis zur Straßenmitte ziehst. Besser wäre es, wenn die Fläche nur den Bereich umfasst, der tatsächlich der realen Parkfläche entspricht (also nur bis zum Fahrbahnrand). Für Anwendungen (z.B. Routing) ist keine Verbindung zur Straße nötig und die Eigenschaften der Parkbucht (z.B. Flächeninhalt/Raumbedarf, Breite des Parkbereichs) können nur korrekt abgeleitet werden, wenn die Fläche der Realität entspricht.

lg, Alex

Hallo SeeIt123, du hast Recht: Hier handelt es sich um wildes, de jure wohl eher ordnungswidriges Parken (je nach dem, wie man "befestigt" auslegt) und ich kann sehr gut nachvollziehen, dass sowas nicht unterstützt werden sollte.

OSM ist aber auch eine Dokumentation der physischen Stadtstruktur, daher ist es eher eine Frage, *wie* das hier eingetragen wird (denn faktisch parken dort leider Autos und die Präsenz von Baumschutzbügeln suggeriert sogar eine gewisse Duldung, um die schlimmsten Schäden zu verhindern). Ich habe die Flächen erstmal wieder reingenommen und um restriktivere Zugangsinformationen ergänzt sowie einen Tag, der die Informalität ausdrückt.

Wie der Zufall will, arbeiten wir als OSM-Community (im Rahmen von https://parkraum.osm-verkehrswende.org/) in Xhain mit dem Bezirksamt gerade zusammen an einer Parkraumanalyse und da sind solche Daten sehr interessant. Das Bezirksamt ist auch bestrebt, solche Zustände nach Möglichkeit aufzulösen. Beim nächsten Zusammentreffen kann ich mal fragen, ob es konkret hier entsprechende Planungen gibt.

Ah – danke für die Bestätigung – als ich da neulich vorbeikam, waren nämlich auf der einen Straßenseite nur Bohrlöcher für die Bügel im Asphalt und ich habe aus der Anzahl der Löcher auf die capacity geschlossen :D

Ja, absolut, das wollte ich nicht in Frage stellen. Description kann und soll in Landessprache verfasst sein. Mir ging es nur um die Tags "disaster_help_point:alert=yes/no" etc. Habe mich auch nicht näher damit befasst, aber es ist mir nur aufgefallen und ich wollte darauf hinweisen.

lg und nichts für ungut, Alex

Ich wollte nur darauf hinweisen, dass die verwendeten Werte in einem internationalen Projekt wie OSM immer überall weltweit gleich verwendet werden müssen, sonst sind die Daten inkonsistent und für Außenstehende nicht sinnvoll verwertbar. Denn OSM ist keine Geodatenbank "für private Zwecke".

Das man auf einer Karte auf einer deutschsprachigen Website dann auch gerne eine deutschsprachige Ausgabe der Attribute haben möchte, muss man außerhalb von OSM erwirken. uMap ist ein gutes Beispiel dafür - der importierte Datensatz müsste dann also vorher so angepasst werden, dass "ja" statt "yes" erscheint oder - je nach Software - eine Übersetzung hinterlegt werden (ich weiß nicht ob uMap das kann).

lg, Alex

P.S. Habe gesehen, dass du/ihr das systematisch auf deutsch macht. Bitte ändert das doch zur dokumentierten und internationalen yes/no-Schreibweise und nutzt auch bei zukünftigen Änderungen yes/no. Ich kann gern dabei behilflich sein, das "rückwirkend" zu ändern, dann gern nochmal melden ;)

lg, Alex

Hallo,

die Bezeichnungen für die Hilfeleistungen am Notfalltreffpunkt sollten besser international einheitlich auf englisch mit "yes/no" statt "ja/nein" bezeichnet werden. So ist es auch dokumentiert: osm.wiki/DE:Tag:emergency%3Ddisaster_help_point

Vielleicht könnt ihr/kannst du das ja nochmal überarbeiten?

Danke für die Ergänzung und beste Grüße
Alex

P.S. Danke @skyper für deine Ergänzung/Korrektur im Wiki. Ich würde da gern demnächst nochmal mehr "aufräumen", falls ich dazu komme bzw. wie gesagt vorher eine Diskussion starten. Vielleicht kann man die Beispiele trennen in "einfache" Beispiele (ohne temporäre Änderungen) und Beispiele für temporäre Busspuren. Und mal sehen, vielleicht gibt es einen Community-Konsens, ausdrücklich zu fomulieren, dass "lanes:psv" im Normalfall ausreichend ist und "psv:lanes" nur bei Mittellagen verwendet werden sollte (so wie bei Radwegen). Damit könnte "lanes:psv" zum Standard-Schema werden. Denn nach so vielen Jahren immer noch drei Schemas parallel zu dokumentieren ist schon ganz schön suboptimal ;)

Ja, genau darauf will ich hinaus. "lanes:psv" (meist "=1") ist in so gut wie allen Fällen ausreichend, es sei denn, die Busspur ist nicht die rechteste Spur. Aber die Dokumentation dazu ist unzureichend bzw. veraltet, erst recht zu temporären Busspuren.

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).