On 11/29/2015 12:28 AM, L. David Baron wrote:
On Sunday 2015-11-08 10:31 -0800, Eric Muller wrote:
I have updated the efele.net/tz maps (http://efele.net/maps/tz/) to be in sync with TZ 2015g. The new zones: It's great to see this updated.
Thanks.
A few comments on the data:
(1) There are a few shapes in the maps that correspond to zones that are now links.
I started the maps while TZ still had a policy that a timezone would be "contained" in a political entity. When the great zone unification happened, I was faced with the choice to apply or not that unification to the maps. As it was a bit unclear where TZ would end up, and because it's easier to merge the shapes for those zones (it only takes data in TZ) than to split them (had I done the unification), I elected to retain as many zones as possible (see my message to this list on July 26, 2014). I took all the zone names that existed, rejected names like Etc/GMT+10, rejected names that are obviously aliases for the same geographical extent (eg Africa/Asmera, retaining Africa/Asmara), and kept all the others. It should be a trivial matter to take any equivalence relation on the zones and produce a map that has a single shape for each class. The equivalence relation could be "zones are linked", or "zones have the same local time over a given period of time".
(2) I noticed that the map uses the Sudanese claim for the border between Egypt and Sudan.
(3) When overlaying on other maps, I notice that the edges of the Aral sea are rather out-of-date.
Obviously, I could not come up with the TZ boundaries ex-nihilo. Because they mostly correspond to land and administrative boundaries, I had to start from an existing map that contains those boundaries. I also wanted a worldwide map, and the result to be as free as possible. The only/best dataset I could find is VMAP0. Unfortunately, that's a relatively old dataset and it has not been updated to account for changes in administrative boundaries. Another case is the Saudi Arabia/Yemen boundary. Arguably, I could try to fix those situations by injecting "better" data. Besides the inherent difficulty of that exercise (where do I get accurate data? how do I stitch it in?), it would also mean that my map could no longer be seen as an additional layer of the VMAP0 dataset. I did the best I could to facilitate the creation of a timezone map using another base dataset, by providing a logical description of the zones, and by publishing the script that relies mostly on FIPS 10-4 identifiers. May be it's time to move the effort to, e.g., OpenStreetMap?
(I've been playing with using the data to draw a "live" timezone map on the Web,
It would be cool to have a dual slider to select a time span for the map. Seeing a timezone as a function relating utc time and local time (over time), you can restrict those functions to a domain via the slider, and distinguish on the map only those functions which are distinct. Eric.