[tz] tz dependency lat & lng

Guy Harris guy at alum.mit.edu
Thu Sep 5 22:50:18 UTC 2013


On Sep 5, 2013, at 2:46 PM, Lester Caine <lester at lsces.co.uk> wrote:

> Guy Harris wrote:
>> If all you have is longitude and latitude, you're going to have to do a geometric search.
> 
> Have you tried?
> Search for Connecticut
> http://www.openstreetmap.org/browse/relation/165794

Let's try a harder problem - let's search for Kentucky, instead:

	http://www.openstreetmap.org/browse/relation/161655

Note that it does *NOT* have a timezone= tag, and there's a good reason for that - more than one tzdb zone covers Kentucky.

So let's look at Louisville:

	http://www.openstreetmap.org/browse/relation/1804307

Hmm.  It doesn't have a timezone= tag, either.

Let's try the county:

	http://www.openstreetmap.org/browse/relation/1804288

Nope, no timezone= tag there, either.

Do you know of an administrative boundary that corresponds to a relation in OSM that *does* have a timezone= tag?  (It should be timezone=America/Kentucky/Louisville, BTW.  Paul, what particular administrative region of Kentucky would be the biggest one that should be tagged with timezone=America/Kentucky/Louisville?  Or *is* there no such region?)

> Now just like TZ, this is still work in progress to get the fine details, but a geometric search within that relation will be able at some point to respond with the timezone of this relation, unless a lower level relation provides it first.

And if you define a set of multipolygon or boundary relations that correspond to the actual borders of tzdb zones, you have only one level of relations to deal with, rather than walking down a hierarchy of those administrative boundaries that happen to be established in OSM (and possibly not finding one with a timezone= tag!)

> The debate at the moment in relation to historic data is if start and end dates should control the visibility of data on the main map. It will on the historic version, but the base map just returns 'today'.
> 
> If someone has time to write a search routine that will access the API and return the timezone then we could have a location tool. All the data is there as usual it's just time which is needed :( Oh for that time machine ...

If by "all the data is there as usual" you mean that, for all points on the surface of the earth, they can be found within *some* relation that's tagged with the correct tzid, I'd need a citation for that claim.


More information about the tz mailing list