On 11/11/2014 03:38 PM, grubernd wrote:
> mh.
>
> also ich habe das bis jetzt so verstanden:
>
> start_date ist das baujahr, [...]
>
> end_date ist das voraussichtliche ablaufdatum, [...]
>
> oder lieg ich da falsch?
Hätt ich so in etwa gesehen und wäre so verwendet auch kein Problem, das
uns
mh.
also ich habe das bis jetzt so verstanden:
start_date ist das baujahr,
das zB auf brücken, häusern, marterln usw ja öfter anschrieben ist.
liegt üblicherweise in der vergangenheit und ist eine info, die nur
ausgewertet werden wird, wenn es jemand drauf anlegt. besonders dadurch
interessan
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. Da
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 P
On 11.11.14 13:34, Werner Macho wrote:
> Nichtsdestotrotz stehen jetzt gerade eben die tags start_date=<> und
> end_date=<> im admin_level=8 der Daten in Österreich.
Man hätte die zukünftigen mit future:boundary taggen können, vor allem sollte
man aber zu Sylvester jene
http://overpass-turbo.e
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 ausges
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=administ
On Mon, Nov 10, 2014 at 10:34:39PM +0100, Friedrich Volkmann wrote:
> On 10.11.2014 19:13, Stephan Bösch-Plepelits wrote:
> > Nun, ich stimme zu, dass es trivial ist. Das heisst aber noch nicht, dass
> > es auch getan wird. Nur als Beispiel, openstreetmap-carto, der Standardstil
> > der OpenStreetM
On 10.11.2014 19:13, Stephan Bösch-Plepelits wrote:
> Nun, ich stimme zu, dass es trivial ist. Das heisst aber noch nicht, dass
> es auch getan wird. Nur als Beispiel, openstreetmap-carto, der Standardstil
> der OpenStreetMap, berücksichtigt start_date und end_date nicht.
Wir können ein Ticket ers
On Mon, Nov 10, 2014 at 06:36:43PM +0100, Friedrich Volkmann wrote:
> On 10.11.2014 15:27, Stephan Bösch-Plepelits wrote:
> > Heute ist uns aufgefallen, dass die neuen Gemeinden in der Steiermark
> > bereits in der OpenStreetMap eingetragen sind und dort als
> > start_date=2015-01-01. Die alten Gem
On 10.11.2014 15:27, Stephan Bösch-Plepelits wrote:
> Heute ist uns aufgefallen, dass die neuen Gemeinden in der Steiermark
> bereits in der OpenStreetMap eingetragen sind und dort als
> start_date=2015-01-01. Die alten Gemeinden sind natürlich auch noch
> eingetragen und haben als end_date=2014-12
Hi!
Heute ist uns aufgefallen, dass die neuen Gemeinden in der Steiermark
bereits in der OpenStreetMap eingetragen sind und dort als
start_date=2015-01-01. Die alten Gemeinden sind natürlich auch noch
eingetragen und haben als end_date=2014-12-31. Das ist zwar durchaus
nicht falsch, ich frage mich
12 matches
Mail list logo