http://overpass-turbo.eu/s/Zf Will take a couple of minutes then ask about large data set. OK US timezone areas need a bit of a tidyup which was why this was taking so long :( I'd certainly be looking to clean up all the little areas back to the bigger boundaries if that is possible, and adding the missing zones ... But THAT is the whole point, we can simply edit this data ourselves. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
On Sep 6, 2013, at 2:06 PM, Lester Caine <lester@lsces.co.uk> wrote:
http://overpass-turbo.eu/s/Zf Will take a couple of minutes then ask about large data set.
OK US timezone areas need a bit of a tidyup which was why this was taking so long :( I'd certainly be looking to clean up all the little areas back to the bigger boundaries if that is possible, and adding the missing zones ... But THAT is the whole point, we can simply edit this data ourselves.
Or we could add the actual tzdb zone bounaries to OSM as relations. Querying *that* probably won't take as long. BTW, it displayed a map with parts of it colored yellow; to what do the yellow and white regions in that map correspond?
Guy Harris wrote:
On Sep 6, 2013, at 2:06 PM, Lester Caine <lester@lsces.co.uk> wrote:
http://overpass-turbo.eu/s/Zf Will take a couple of minutes then ask about large data set.
OK US timezone areas need a bit of a tidyup which was why this was taking so long :( I'd certainly be looking to clean up all the little areas back to the bigger boundaries if that is possible, and adding the missing zones ... But THAT is the whole point, we can simply edit this data ourselves.
Or we could add the actual tzdb zone bounaries to OSM as relations. Querying *that* probably won't take as long.
The query being run is on the left. It's looking for all nodes, ways and relations with a tag of timezone. We can probably ignore nodes anyway, and the few ways are questionable since they may not create a closed area. I took off the first to XML blocks just leaving relations block.
BTW, it displayed a map with parts of it colored yellow; to what do the yellow and white regions in that map correspond? The yellow areas were the found timezones. Click on them to get the details. There were circles which flag the nodes. The white areas are missing timezone tags :( Which is why Louiseville is not giving one.
-- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
On Sep 6, 2013, at 3:09 PM, Lester Caine <lester@lsces.co.uk> wrote:
The yellow areas were the found timezones. Click on them to get the details. There were circles which flag the nodes. The white areas are missing timezone tags :( Which is why Louiseville is not giving one.
But that's not why the state of New York is not giving one, because it *does* have such a tag: http://www.openstreetmap.org/browse/relation/61320
On Fri, 6 Sep 2013, Guy Harris wrote:
On Sep 6, 2013, at 2:06 PM, Lester Caine <lester@lsces.co.uk> wrote:
http://overpass-turbo.eu/s/Zf Will take a couple of minutes then ask about large data set.
OK US timezone areas need a bit of a tidyup which was why this was taking so long :( I'd certainly be looking to clean up all the little areas back to the bigger boundaries if that is possible, and adding the missing zones ... But THAT is the whole point, we can simply edit this data ourselves.
Or we could add the actual tzdb zone bounaries to OSM as relations. Querying *that* probably won't take as long.
We actually have discussed that before, but TZDB boundaries do not really belong in OpenStreetMap. It is something that is very difficult to indepedently survey on the ground! I would probably suggest to keep a separate resource that links a TZDB ID to a (list of) OSM boundary relations. With the help of the shapefiles at http://efele.net/maps/tz/world/ that should be doable. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug Posted with an email client that doesn't mangle email: alpine
Derick Rethans wrote:
On Fri, 6 Sep 2013, Guy Harris wrote:
On Sep 6, 2013, at 2:06 PM, Lester Caine <lester@lsces.co.uk> wrote:
http://overpass-turbo.eu/s/Zf Will take a couple of minutes then ask about large data set.
OK US timezone areas need a bit of a tidyup which was why this was taking so long :( I'd certainly be looking to clean up all the little areas back to the bigger boundaries if that is possible, and adding the missing zones ... But THAT is the whole point, we can simply edit this data ourselves.
Or we could add the actual tzdb zone bounaries to OSM as relations. Querying *that* probably won't take as long.
We actually have discussed that before, but TZDB boundaries do not really belong in OpenStreetMap. It is something that is very difficult to indepedently survey on the ground! I would probably suggest to keep a separate resource that links a TZDB ID to a (list of) OSM boundary relations. With the help of the shapefiles at http://efele.net/maps/tz/world/ that should be doable.
I've got a mashup which is a clone of the mapit code and designed to handle area material. I'm just looking at how the local database is populated from OSM, for particular areas, and the timezone tag is already present in OSM and on the whole accurate. The OSM data also returns administrative areas which may be suitable to record changes to tz coverage over time and that will be my next point of interest. My own plan is a web service that returns a timezone for a location and can also return the history of that location back in time. As well as obviously giving a calendar of time changes. Even if only for my private use ... Tidying this information within OSM is a discussion for the OSM list. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
participants (3)
-
Derick Rethans -
Guy Harris -
Lester Caine