On 11/11/2014 02:40 PM, Friedrich Volkmann wrote: > On 11.11.2014 13:13, Andreas Labres wrote: >> Ich hatte das schon mal bei anderer Gelegenheit geschrieben: Es ist >> grundsätzlich NICHT sinnvoll, dass ein zweiter Tag die Beutung des >> ursprünglichen Tags umdreht, verändert, einschränkt, etc. Das war auf bei >> highway=primary, construction=yes das Problem, weshalb die jetzige Variante >> mit >> highway=construction, construction=primary noch die beste ist. > > Ich sehe das nicht so, dass start_date und end_date die *Bedeutung* > verändern, sondern sie bringen nur eine vierte Dimension (Zeitachse) in OSM > ein. Ob wir diese überhaupt haben wollen, ist eine andere Frage.
Mit der vierten Dimension geb ich dir Recht, aber für mich lautet die Antwort spontan eher nein. Also ganz sicher nicht wenn das heißt, dass jeder, der die Daten verwenden will sich selbst um das Auswerten dieser vierten Dimension in all ihren Ausformungen (Formate, Zeitzonen, Sommerzeiten, etc.) kümmern muss. D.h. natürlich nicht, dass opening_hours oder so nicht in OSM sein sollten, denn die spezifizieren ja nur Eigenschaften eines konstant vorhandenen Objekts. Wenn ich aber an jedem Objekt mit einer Zeitinformation rechnen muss ab denen es nicht mehr existiert oder erst existieren wird, dann macht das die Auswertung deutlich komplizierter. Nicht unlösbar, aber imo absolut unnötig kompliziert. Wenn aber die Mapper das Gefühl haben, dass sowas wichtig ist, und sie unbedingt solche Zeiten eintragen wollen, dann sollte das imo in der API gelöst werden, so dass ich dann sagen kann, ich möchte aktuelle Daten zum Zeitpunkt t oder von mir aus in der Zeitspanne t+d haben. Ich persönlich verwend nur end_date und das nur auf Baustellen, die ich von name="Baustelle (mit allen möglichen wichtigen und vor allem unwichtigen Zusatzinfos)" umgetagged hab und da seh ich das Datum eher als Note für andere Mapper. Noch dazu wo die Daten auf den Baustellenschildern ohnehin selten eingehalten werden, wenn die Baustelle nur groß genug ist. Imo sollte es für ein Crowdsourcing Projekt möglich sein Änderungen halbwegs zeitnah einzupflegen. Wenn das nicht passiert, dann war's wohl noch keinem wichtig genug, was eigentlich ein ganz guter Filter ist. >> Das ist auch ganz nachvollziehbar: Wenn ich eine Overpass-Query nach >> amenity=restaurant mache, dann will ich alle Restaurants. Und zwar die jetzt >> gültigen. Alles was vielleicht früher mal eins war, sollte jetzt sowas wie >> former:amenity=restaurant sein. > > Damit fehlt aber die Information, wann das existiert hat. Mit der > Information alleine, dass es irgendwann existiert hat. lässt sich nicht > wirklich was anfangen. Besser entweder ordentlich (mit Datum) oder gar nicht > in der Datenbank halten, sonst ist es nur Datenmüll. Die Information ist ungefähr im Changeset enthalten. Wenn das nicht genau genug ist, dann kann man es auch an das Objekt selbst taggen, aber wenn man es zusätzlich zum former: Prefix tagged, dann ist allen geholfen. Denen, die nur nach aktuell gültigen Objekten suchen und denen, die ganz exakt wissen wollen, ab welchem Zeitpunkt die Daten veraltet waren. Aber eigentlich denk ich sollte alles in der DB sein was aktuell ist und dann geändert werden, wenn es sich geändert hat. Ganz ohne die Verrenkungen um alle möglichen Zustände seit es OSM gibt (oder gar noch viel länger) zu erfassen. Wer das braucht sollte die History auswerten. Norbert _______________________________________________ Talk-at mailing list Talk-at@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-at