Hallo,

das ist hier osm.wiki/DE:Lebenszyklus-Pr%C3%A4fix beschrieben.
In diesem Fall macht man aus dem shop=car ein disused:shop=car.
Was man auch immer schon mal schauen kann: Sind die Schilder noch dran, sonst kann der Name weg; opening_hours ist in der Regel hinfällig usw.
Wichtig: Wenn wie hier die Adresse am Gebäudeumriss hängt, diese natürlich nicht entfernen.

Bei Fragen einfach melden.

Viele Grüße

Beim Kopieren verloren gegangen: Objekt war node/10685822131

Hallo,

im Rahmen einer Requestbitte nur wenige Meter weiter bin ich auf diesen Notfalltreffpunkt gestoßen. Ich habe mir keine weiteren Notfalltreffpunkte in der Region angesehen, falls sich mein Hinweis auf weitere gleichartige Objekte beziehen sollte, bitte ich um Beachtung.

1. addr-Schema
Die Verwendung ist in dieser Form problematisch. Wenn überhaupt, kann das object-Schema genutzt werden. Wie schon hier changeset/159037255 beschrieben, halte ich auch das für problematisch.
Hausnummern werden mit (Komma oder) Semikolon getrennt.

2. location
Die Verwendung ist so nicht üblich, es müsste indoor=yes|no sein.

3. Namen
official_name=Notfalltreffpunkt und reg_name=Katastrophenschutz-Leuchtturm werden hier falsch eingesetzt; sie sind in diesem konkreten Beispiel keine „Alternativen“ zu name (Freiwillige Feuerwehr Aachen, LZ 20).
Ein richtiges Beispiel wäre name=Kölner Dom, official_name=Hohe Domkirche Sankt Petrus.
Derartige Abfragen (Notfall-Anlaufpunkt |Katastrophenschutz-Leuchtturm| Notfall-Infopunkt |Notfalltreffpunkt) sind durch den Datennutzer zu klären, nicht bereits an der Quelle. Wenn es um die Auffindbarkeit in Nominatim geht: hier sind die „Suchwörter“ beschrieben: osm.wiki/Nominatim/Special_Phrases/DE

4. permanent
Laut Wiki (osm.wiki/DE%3ATag%3Aemergency%3Ddisaster_help_point) ist der (noch ungeklärte) Tag gedacht „um zu deklarieren, ob dieser Ort als allgmeine Anlaufstelle dient, oder nur für ein bestimmtes, einmaliges Ereignis eingerichtet“ wird.
Sicher, dass dieser Punkt (bei einem Freiwilligen Löschzug) ständig besetzt ist?

5. website
Die Erwartungshaltung dürfte eher sein, dass eine Seite für den Endnutzer erscheint.

Ich halte die Erfassung solcher Objekte für einen sehr sinnstiftenden Einsatz von OSM. Daher: Weiterhin viel Erfolg.

Viele Grüße

Hallo und herzlich willkommen bei OpenStreetMap.

Vielen Dank für deinen Beitrag. Du hast um Prüfung deiner Anpassung gebeten.
Du hast dir für den Einstieg eine sehr anspruchsvolle Aufgabe ausgesucht.

Ich versuche mal, das ganze zu sortieren.
Das Gelände des Feuerwehrhauses besteht aus zwei Gebäuden und damit zwei Adressen, was recht ungewöhnlich ist.
Du hast am Gebäude way/221659226 den namen „Freiwillige Feuerwehr Aachen, LZ 20“ ergänzt. So heißt aber nicht das Gebäude, sondern das „Gesamtensemble“.
Am Gebäude way/192615181 wiederum hängt das eigentlich wichtige Tagging, das amenity=fire_station. Das ist aber dann an diesem Gebäude allein falsch aufgehoben.
Was ist zu tun?
Am Gebäude way/221659226 muss der Name wieder raus.
Am Gebäude way/192615181 muss der Name und alles mit Feuerwehrbezug raus.
Diese Daten gehören stattdessen an das Gelände. Falls das hier way/783918730 vielleicht schon das Gelände sein sollte, gehören amenity=fire_station usw. da dran.
Auch das ref solltest du noch mal prüfen. Was ist richtig: LZ-S oder LZ 20? Das sind auch die Kürzel, die in der openfiremap auftauchen.
Klingt jetzt erst mal kompliziert – daher: bitte melde dich, wenn du Unterstützung benötigst.

Viele Grüße

Hallo,
ich bin über diesen Weg gestolpert, weil ein review_requested=yes im Änderungssatz gesetzt wurde.
Die Beschreibung ist - trotz oder gerade wegen des hoheitlichen Anstrichs - sehr kurz und so nicht nachvollziehbar.
Was ist denn der Grund für die Löschung?
Viele Grüße

Hallo,
hier ist etwas schief:

Jetzt eingetragen:
building=fire_station
construction=fire_station

Es sollte sein
1)
building=construction
construction=fire_station

oder

2)
Das construction=fire_station muss raus.

Viele Grüße

Hallo und herzlich willkommen bei OpenStreetMap.
Du hast um eine Prüfung deiner Änderungen gebeten.
Vielen Dank für deinen Beitrag, das sieht sehr gut aus.
Bei Überflurhydranten sind folgende Angaben ebenfalls sinnvoll:
fire_hydrant:diameter
fire_hydrant:position
und auch
couplings (z.B. 3)
couplings_diameter (z.B. A;B;B)
Vielleicht möchtest du diese Angaben noch ergänzen.
Wenn du Fragen hast: gerne hier im Änderungssatz oder bei der nächsten Anpassung wieder den Haken für die Prüfbitte setzen.
Viele Grüße

Hallo,

der Hinweis bei cycleway=opposite (osm.wiki/DE:Tag:cycleway=opposite?uselang=de) ist eigentlich recht eindeutig:

"Unter keinen Umständen sollte dieses »überholte« Tag in größerem Umfang (semi-)automatisch geändert werden, ohne den Verhaltenskodex für automatisierte Änderungen zu beachten. Jede dieser Änderungen wird revertiert."

Bitte beim beim nächsten Mal beachten.

Viele Grüße

Hallo,

du hast um einen Review gebeten.
Diesem Wunsch komme ich gerade bei diesem sehr interessanten Thema gerne nach.
Großes Lob auch für die Projektseite.

Ich habe folgende Anmerkungen:

location
Die Angabe location=indoor|outdoor ist unüblich. Diese Angabe erfolgt traditionell über indoor=yes|no

srac:id
Für derartige Angaben wird in der Regel das ref-Feld genutzt. Wenn das nicht möglich sein sollte, wäre das Anlegen einer Wiki-Seite sinnvoll, um den Einsatz zu dokumentieren.

Adressen
Das object:-Schema ist definitv ein Fortschritt gegenüber dem addr:-Schema, ich möchte aber nicht verhehlen, dass viele Mapper (ich schließe mich ein) dem Thema kritisch gegenüber eingestellt bin. Wenn man die Wiki-Seiten zu object:*=* zwischen en/de vergleicht, stellt man schnell fest, dass es scheinbar ein deutsches Phänomen ist.
Es spricht einiges gegen das Schema:
Wozu soll es dienen?
Bei Freiluftobjekten: wonach bemisst sich die Adresse? Nach dem nächsten Eingang, nach dem Grundstück?
Wer synchronisiert Änderungen? Objektstandorte können sich ändern, Adressen auch (vgl. ganz aktuell den Fall Audre-Lourde-Straße/Berlin)
Erschwert wird das dadurch, dass Adressen in OSM durchaus schon einmal anders (in der Regel besser) als die amtlichen Daten sein können. Je nach Datennutzer und Ökosystem (z. B. Google) kann das zu unerwünschten Abweichungen führen.
Spätestens wenn an einer Adresse mehrere Objekte erfasst sind, geht die Eindeutigkeit verloren.
Man merkt vielleicht: ich bin hier Hardliner; das Erfassen von Adressen - in welchem Schema auch immer - ist meiner Meinung nach aus der Zeit gefallen. Aber gut jetzt ;-)

Und wenn man es schon macht, sollte man es sehr sorgfältig machen.
Nur einige Beispiele nach kursorischer Prüfung:

Der Defi node/12334011230 trägt eine Objekt-Adresse, die jedoch tatsächlich woanders liegt way/83734744

Die Stadt ist hier node/12334011281 “Stolberg-Vicht”, das Gebäude dazu trägt “Stolberg (Rhld.)” (way/203268436)

Hier node/1012321635 ist die Straße “Mies-van-der-Rohe-Strasse”, hier
node/11860728173 “Mies-van-der-Rohe-Straße”

gelöschte Objekte
Ich finde es schwierig, dass gelöschte Objekte in diesem großen Changeset verschwinden. So ist nicht nachvollziehbar, warum sie gelöscht wurden. Zumal dann, wenn ein Node node/1012318010 gelöscht wird und direkt daneben ein neuer entsteht (node/12334011289)

Viele Grüße

Hallo,
ich habe wie gewünscht einen Review vorgenommen und nur zwei kleinere Anmerkungen:
Die Linie schneidet das Gebäude bzw. der Weg verläuft darunter (layer=-1) way/878946723
Hier way/1333260921 ergibt das layer=-1 ebenfalls keinen Sinn
Weiter so!
Viele Grüße

Hallo,

du hast um eine Prüfung deiner Anpassung gebeten.
Ich sehe hier drei Probleme:
- Landuses haben in der Regel keinen Namen
- Das Gebiet ist bereits als Wohngebiet erfasst, siehe www.openstreetmap.org/way/313527219
- Flächen sollten nicht mit Straßen verklebt werden, hier mit der Eikelmannstraße
Also am besten wieder löschen, ist ja schnell gemacht. Vielen Dank für deinen Beitrag, bitte melde dich, wenn du Fragen hast.

Viele Grüße

Hallo und herzlich willkommen bei OpenStreetMap.

Du hast um eine Prüfung deiner Anpassung gebeten.
Eine Frage vorab: welches Luftbild hast du verwendet? Laut Angabe im Changeset war es Bing, das ist bei mir in dem Bereich aber nicht aktuell.

zu www.openstreetmap.org/way/1332791309:
- Landuses bekommen in aller Regel keinen Namen
- Man kann sich streiten, ob das hier nicht eigentlich landuse=construction wäre (dann wäre auch der Name nicht problematisch, der verschwindet ja mit Ende der Bauzeit wieder.)
- Das Landuse ist so in dieser Form definitiv redundant; es ist bereits mit www.openstreetmap.org/relation/3342319 erfasst

Auffahrten haben keinen Namen („Auffahrt“)

zu www.openstreetmap.org/way/1332791308 (als Beispiel):
- name ist überflüssig bzw. falsch
- Die Kombination building=house und house=semi-detached geht kürzer als building=semidetached_house.
- Das semidetached kann nicht stimmen, da der Baukörper freistehend ist

Vielen Dank für deinen Beitrag; gerade solche Informationen können nur von Beitragenden wie dir aus der lokalen Gemeinschaft kommen.
Bitte melde dich, wenn du Fragen hast.
Viele Grüße

Hallo,
ich möchte auf meinen Kommentar in changeset/158974024 hinweisen.
Viele Grüße

Hallo und herzlich willkommen bei OpenStreetMap.
Du hast um eine Prüfung deiner Anpassung gebeten.
Du hast eine undankbare Aufgabe erwischt; der Weg war bereits vor deiner Anpassung ungewöhnlich erfasst. Es war ein Feld- oder Wirtschaftsweg, zu dem nur Eigentümer mit Kraftfahrzeugen Zugang haben, aber niemand zu Fuß. Fahrräder dürften also z. B. fahren.
Jetzt hast du es so geändert, dass es ein Fußweg ist – den aber Fußgänger nicht nutzen dürfen.
Lass dich davon nicht entmutigen, so etwas kommt bei OSM schon mal vor. Du hast jederzeit die Möglichkeit, solche Dinge zu verbessern und auch die Arbeit deiner „Vorgänger“ zu optimieren.
Wie ist der Weg denn ausgeschildert? Letztlich kommt es darauf an.
Wenn du Fragen hast: bitte melden.
Viele Grüße

Hallo,
ich denke, hier ist etwas schiefgegangen. Du hast einen Amazon-Locker neu angelegt und mit gleichen Daten eine Fahrradbox umgetaggt?
Viele Grüße

Hallo und herzlich willkommen bei OpenStreetMap.
Vielen Dank für deinen Beitrag; gerade solche Informationen können nur von Beitragenden wie dir aus der lokalen Gemeinschaft kommen.
Ich versuche einmal nachzuvollziehen, was du vorhattest.
Du hast festgestellt, dass einzelne Straßenlampen (highway=street_lamp) nicht mehr vorhanden sind.
Du hast – völlig korrekt (und sehr fortgeschritten!) – festgestellt, dass ein einfaches Löschen schwierig sein kann, weil eventuell auf Luftbildern oder in Mapillary die Lampen noch erkennbar sein und ggf. wieder versehentlich eingetragen werden könnten. Daher hast du dich am Lifecycle-Prefix orientiert und festgestellt, dass dann „razed“ vorangestellt wird.
Und ab hier kann ich dir nicht mehr ganz folgen.
Ein razed:highway=street_lamp hätte dich bereits ans Ziel gebracht. Stattdessen hast du einen „abgerissenen Hochspannungsmast“ ergänzt. Vielleicht nur ein Missverständnis?
Über eine Rückmeldung würde ich mich sehr freuen.
Viele Grüße

Hallo,
mach dir keinen Stress.
Sieht gut aus!
Weiterhin viel Erfolg und frag bitte einfach nach, falls du mir mal unsicher bist.
Viele Grüße

Super, danke dir

Hallo,
du hast um eine Prüfung deiner Bearbeitungen gebeten.
Eine kurze Erläuterung zu Brücken; es gibt zwei getrennte Objekte:
- Highway=*, an denen die Brückeneigenschaft mit bridge=yes ergänzt wird
- Brückenkörper man_made=bridge
Die entsprechenden highway=Stücke sind bereits alle gesperrt. Diese sind maßgeblich für das Routing, die meisten Kartendarstellungen usw.
Deine Änderung bezieht sich auf den Brückenkörper – das hat aber keinerlei Auswirkungen.
Bei Fragen: jederzeit gerne!
Viele Grüße

Ja, okay!