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

Hallo Jens, bei der Bearbeitung des 0%-Spätis hast du glaub ich ausversehen bei diesem Arzt den Namen gelöscht, kann das sein? osm.org/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? osm.org/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 (osm.org/node/10589654475) und dieser (osm.org/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