[Talk-at] Objekte mit start_date/end_date

Norbert Wenzel norbert.wenzel.lists at gmail.com
Tue Nov 11 14:04:43 UTC 2014


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






More information about the Talk-at mailing list