Geolocation extension to tzdist
All, (sending to tz@iana.org since tzdist@ietf.org appears to be dead) I was bored today (actually avoiding "real" work) and was playing around with the ESRI shapefile for timezones <http://efele.net/maps/tz/world/> I hacked up a quick extension to my tzdist implementation using the tz_world shapefile and basic ray tracing to be able to query a time zone by geo coordinates, similar to what Google offers in their Time Zone API. Note that I have yet to spend any time writing code to account for "holes" in time zones like the Navajo Reservation in Arizona. I modeled the extension after the "find" action in RFC 7808 but with lat/long query params rather than a glob pattern. A request and response for the timezone in which my home is located looks something like this: GET /tzdist/zones?latitude=43.070833&longitude=-78.831667 HTTP/1.1 { "synctoken": "890939292-1466089793", "timezones": [ { "tzid": "America/New_York", "etag": "6602582-1466089793", "last-modified": "2016-06-16T15:09:53Z", "publisher": "IANA Time Zone Database", "version": "2016e", "aliases": [ "US/Eastern" ] } ] } The definition of the extension looks like this in the capabilities response: { "name": "geolocate", "uri-template": "/zones{?latitude,longitude}", "parameters": [ { "name": "latitude", "required": true }, { "name": "longitude", "required": true } ] } Currently my code only accepts coordinates in decimal degrees, but I think it should probably support ISO 6709 formats. Is this something that folks would like to see documented as a formal extension to tzdist, either as specified above or with some modification? If so, I'd be willing to write it up as a draft and then move it through IETF in whatever fashion the ADs recommend. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University
Ken Murchison wrote:
Is this something that folks would like to see documented as a formal extension to tzdist, either as specified above or with some modification?
I think it's a good thing to have. It might also be helpful to be able to query for the containing shape, though that will take more work.
I was thinking of doing something similar for my own product. Glad you are taking the opportunity to look into it. On 2016-09-29 21:31, Paul Eggert wrote:
Ken Murchison wrote:
Is this something that folks would like to see documented as a formal extension to tzdist, either as specified above or with some modification?
I think it's a good thing to have. It might also be helpful to be able to query for the containing shape, though that will take more work.
--
On Thursday, September 29 2016, "Ken Murchison" wrote to "tz@iana.org" saying:
All,
(sending to tz@iana.org since tzdist@ietf.org appears to be dead)
I was bored today (actually avoiding "real" work) and was playing around with the ESRI shapefile for timezones
I hacked up a quick extension to my tzdist implementation using the tz_world shapefile and basic ray tracing to be able to query a time zone by geo coordinates, similar to what Google offers in their Time Zone API. Note that I have yet to spend any time writing code to account for "holes" in time zones like the Navajo Reservation in Arizona.
I'd suggest that people do want to standardize this, something based on LoST (RFC 5222) would probably be a good starting point for time zone geolocation. That's a protocol that's designed for all the complexity of how locations can be represented. -- Jonathan Lennox lennox@cs.columbia.edu
All, I just posted a first draft of my geolocate extension: https://tools.ietf.org/html/draft-murchison-tzdist-geolocate-00 I switched to using the existing geo URI format for specifying location at the suggestion of one of the authors of TZDIST. The draft includes an example of doing a query using an uncertainty value. You can give my test implementation a test drive here: https://cyrus-test.andrew.cmu.edu/tzdist/zones?location=geo:36.01596,-114.73... That server is using Evan Siroky's new shapefiles. Note that the implementation is not perfect yet as I'm not checking for holes in timezones, nor doing any calculations when a location is in international waters. Also note that the calculations for finding time zones within an uncertainty range are based on the earth being a sphere (using mean radius), not a spheroid. I may change this later, but I'm not sure that it matters over short distances. Finally, there is no data for Antarctica. On 09/29/2016 06:38 PM, Ken Murchison wrote:
All,
(sending to tz@iana.org since tzdist@ietf.org appears to be dead)
I was bored today (actually avoiding "real" work) and was playing around with the ESRI shapefile for timezones <http://efele.net/maps/tz/world/>
I hacked up a quick extension to my tzdist implementation using the tz_world shapefile and basic ray tracing to be able to query a time zone by geo coordinates, similar to what Google offers in their Time Zone API. Note that I have yet to spend any time writing code to account for "holes" in time zones like the Navajo Reservation in Arizona.
I modeled the extension after the "find" action in RFC 7808 but with lat/long query params rather than a glob pattern. A request and response for the timezone in which my home is located looks something like this:
GET /tzdist/zones?latitude=43.070833&longitude=-78.831667 HTTP/1.1
{ "synctoken": "890939292-1466089793", "timezones": [ { "tzid": "America/New_York", "etag": "6602582-1466089793", "last-modified": "2016-06-16T15:09:53Z", "publisher": "IANA Time Zone Database", "version": "2016e", "aliases": [ "US/Eastern" ] } ] }
The definition of the extension looks like this in the capabilities response:
{ "name": "geolocate", "uri-template": "/zones{?latitude,longitude}", "parameters": [ { "name": "latitude", "required": true }, { "name": "longitude", "required": true } ] }
Currently my code only accepts coordinates in decimal degrees, but I think it should probably support ISO 6709 formats.
Is this something that folks would like to see documented as a formal extension to tzdist, either as specified above or with some modification? If so, I'd be willing to write it up as a draft and then move it through IETF in whatever fashion the ADs recommend. -- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University
-- Kenneth Murchison Principal Systems Software Engineer Carnegie Mellon University
Ken Murchison wrote:
I just posted a first draft of my geolocate extension: https://tools.ietf.org/html/draft-murchison-tzdist-geolocate-00
Thanks for the work, and for the heads-up. Proposed patch to tz-link.html attached.
participants (4)
-
David Patte ₯ -
Jonathan Lennox -
Ken Murchison -
Paul Eggert