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 <[email protected]>: > 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 > [email protected] > https://lists.openstreetmap.org/listinfo/talk-at _______________________________________________ Talk-at mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-at
