Ich bin der Meinung, daß “Dauerhaftes” in die Datenbank gehört. “Nicht Dauerhaftest” gehört auch nicht in die Datenbank.
Wo die Grenze zu “Dauerhaft” ist, sollte jeder selber entscheiden. Wenn Die Autobahn “A7” für 4 Wochen voll gesperrt ist, gehört das in die Karte, wenn bei Oma Erna für 4 Wochen der Mini-Bagger vor der Tür steht macht es eher weniger Sinn für die Karte. Aber Entscheiden sollte das derjenige, der es einzeichnet und am Ende auch wieder löscht.
Und genau hier ist das Problem mit den Osterfeuern. Die müsste man Deutschlandweit ja am 31.3. um 20 Uhr eintragen und nach 4 Stunden schon wieder austragen. Denn danach ist es nur ein Platz mit verbrannter Erde, ein paar Tage oder Wochen davor ein Lagerplatz für Holz.
Für “Nicht Dauerhaftes” wäre vielleicht ein Zusatzdienst eine geniale Sache. Eine “Temorär-Datenbank” die Osterfeuer, Weihnachtsmärkte, “Tag der Offenen Tür-Gebiete”, Tagesbaustellen, usw. verwaltet. Aber so etwas gibt es aktuell glaube ich nicht.
Ich wollte gerade für die kindliche Verwandtschaft die geplanten Osternester-Standorte mappen und dann per geocaching am Sonntag suchen lassen. Geht aber leider nicht, weil Server gesperrt
Falls eins dennoch nicht gefunden werden sollte, hätte ich mit meinem dementen Hirn später noch mal eine Chance.
So könnte man diesen schönen alten Brauch den kindlichen Technik-freaks doch wieder nahe bringen.
vielleicht kam das nicht so ganz rüber und ist im ersten Beitrag auch nicht ganz deutlich. Es geht nicht um ein Osterfeuer an sich, sondern um eine über das ganze Jahr hinweg existierende Feuerstelle, die wohl hauptsächlich zu Ostern genutzt wird. Wenn man da sonst Feuer machen will, braucht man irgendwelche Genehmigungen.
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”.
… 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.