[Talk-at] Objekte mit start_date/end_date

Werner Macho werner.macho at gmail.com
Tue Nov 11 12:34:53 UTC 2014


Hi!

Nichtsdestotrotz stehen jetzt gerade eben die tags start_date=<> und
end_date=<> im admin_level=8 der Daten in Österreich.
Prinzipiell find ich die Idee ja gut .. aber ich wäre ohne Stephan
nicht auf die Idee gekommen und hab mich immer gefragt wieso da grad
alles (also einiges) doppelt ausgespuckt wird (beim Checken auf
Überlappungen im GIS).

Gerade "date" wirft bei mir aber die Frage auf welches Format?
Immerhin wird in verschiedenen Ländern das Datum auch unterschiedlich
geschrieben. In Österreich steht es gerade als "2014-12-31" drinnen,
was jetzt eher einer international Einheitlichen Schreibweise
entspricht (zumindest ich würde als Österreicher das Datum andersrum
schreiben).

Mit dem Wissen das so etwas da ist ist für mich das Problem ja nun
gelöst, aber ob und vor allem wie das "richtig" eingetragen gehört
scheint ja noch nicht komplett geklärt zu sein.

Danke für all die Info schon mal
Liebe Grüße
Werner


2014-11-11 13:13 GMT+01:00 Andreas Labres <list at lab.at>:
> On 10.11.14 19:13, Stephan Bösch-Plepelits wrote:
>> Nun, man könnte analog etwas wie bei Straßen machen. Dort ist ja während der
>> Bauzeit highway=construction, construction=primary eingetragen. Nach Eröffnung
>> wird das dann umgetaggt. Also vielleicht boundary=construction,
>> construction=administrative???
>
> 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.
>
> 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. So könnte man das auch bei den Admin-Boundaries
> lösen: alles, was jetzt gültige Grenze ist, ist boundary=administrative, alles,
> was früher mal war, former:boundary=administrative.
>
> Das Verändern des Keys hat übrigens Vorteile gegenüber einem Verändern der Value
> (siehe Beispiel highway=construction): Hieße der Key
> construction:highway=primary, würden bei der Query nach "highway" wirklich nur
> die jetzt gültigen Wege rausfallen, nicht eben auch die in Bau befindlichen oder
> gar die geplanten. Detto fallen bei "amenity" alle die ehemaligen POIs raus, die
> jetzt "former:amenity" sind. Macht Sinn, ist IMO die "verträglichste" Methode,
> nicht irgendjemand anderes Code zu brechen.
>
> /al
>
> _______________________________________________
> Talk-at mailing list
> Talk-at at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at




More information about the Talk-at mailing list