Netzwolf
(Netzwolf)
24
Nahmd,
Da kann man zwischen dem Ort und dem Ereignis unterscheiden:
– der Ort (so ganzjährig sichtbar/erkennbar) gehört in die OSM-Datenbank;
– die Veranstaltungen passen möglicherweise besser in eine getrennte Datenbank und dann in ein Overlay. Leider ist “osterfeuer.de” schon gesquatted.
– regelmäßig (wenn auch selten) an einem bestimmten Ort stattfindende Ereignisse kann ich mir auch gut in der OSM-DB vorstellen. Da kann man aber auch ganz anderer Meinung zu sein.
In der Aktualität der Daten liegt unser Vorteil. Den sollten wir nicht leichtfertig aufgeben. So können wir leicht die (geplante) Dauer auch einer Kurzbaustelle mit erfassen. Sofern das Tag einheitlich gehandhabt wird und korrekt ausgefüllt ist (opening_hours ist für diesen Zweck zu komplex und auch unpassend) können die Auswerter, egal ob Router oder Renderer, die Datensätze enstprechend der gewünschten Gültigkeit selektieren.
Letzte Woche noch habe ich einem Truckfahrer aus der Klemme helfen müssen, den sein Navi völlig korrekt geleitet hatte bis zu einem wegen Baustelle geschlossenen Bahnübergangs, dessen Umgehung weder ausgeschildert noch offensichtlich war. Der wäre über aktuelle Daten glücklich gewesen. (Ich bin mutig ins Führerhaus geklettert und mein “wetware”-Navi hat ihn dann ans Ziel geleitet.)
Als Grundlage für das Tagging nutzen kann man “ist es da?” oder “kann/darf man es benutzen?”. Um das Taggingschema einfach zu halten, würde ich für beides die gleichen Tags benutzen, aber unbedingt nicht nutzbare Einrichtungen mit “access=no” oder “access=private” kennzeichnen.
Dann kann ein an nutzbaren Objekten interessierter Datennutzer sehr einfach die nicht nutzbaren tilgen; in unserem Beispiel: grillkarte.de zeigt nicht die Osterfeuerstellen.
Vielleicht sollten wir dem OSM-Daten-Verarbeitern die Arbeit erleichtern, die hängen ohnehin immer hinterher (Mapnik vs. natural=scree und natural=fell
… ceterum censeo…). Sobald alle Dein “fire=no” implementiert haben, komme ich mit “amenity=bench;sitting=no”. Wenn wir da ein eher universelles Tag nehmen (access=no), haben die Verarbeiter auch eine Chance, das zu implementieren.
Und allem “wir taggen nicht für die Renderer”-Gerede zum Trotz: es ist wichtig, was und wie gerendert wird. Zuletzt hat ein Saubermann eine von mir erfasste “amenity=toilett; access=private” aus der DB getilgt “mangels Relevanz” (offensichtlich ein Wikipedianer). Gemeint war wohl “weil an der Stelle kein Toilettensymbol erscheinen soll”.
event:type=bonfire
event:name=Osterfeuer
event:opening_hours=…

Gruß Wolf