[Tagging] Mapping time zones as geometries (relations)

[Colin Smale]

On 2017-03-07 07:43, Frederik Ramm wrote:

> Kevin,
> 
> On 03/07/2017 02:06 AM, Kevin Kenny wrote: 
> 
>> There are reasonable use cases for wanting to take a timezone name and
>> get back a multipolygon
> 
> Question is, does (the core database of) OSM have to fulfil these use cases!
> 
>> or to get a list of name and multipolygon for
>> all the timezones (or all the timezones on a given map). That's hard to
>> do unless there are relations for the timezones. Not impossible, we
>> could query administrative boundaries for the tag, but that's likely to
>> be SLOW since the tag will at best be in hstore and not indexed.
>> Grouping disjoint items, such as "all the administrative regions in a
>> time zone" seems tailor-made for relations.
> 
> In my opinion, no. We've been there - people (ab)using relations like
> some kind of bookmark, to make data retrieval easier (e.g. a relation
> "all cycleways in XY city" just because it was slow/difficult to
> retrieve them otherwise).
> 
> You would typically use a relation to group things when they can be in
> more group than one, and therefore tagging the membership on the
> individual object becomes cumbersome - cycle, bus, or hiking routes are
> a prime example, since the same street/way can be part of several of them.
> 
> Not so with time zones, I should hope; a region can only be associated
> with exactly one (not 0, not more than one) time zone. Hence adding a
> time zone tag to the object is the easiest way to maintain the data and
> to ensure that you don't accidentally have two!
> 
> I agree it might make things a little more difficult for the consumer
> but an overpass query can quickly find every boundary relation tagged
> with a certain time zone, and I'm sure sooner or later specialist sites
> will take the data and prepare daily updated json files or whatever that
> one can overlay on a map.

It is possible to have enclaves/exclaves for a territory which differs
from the surrounding territory. Taking the US as an example, if we put a
timezone tag on a State, there may need to be an overriding tag on a
County or even possibly at a City level. There are also native homelands
that cross state boundaries which have their own ideas about time. See
[1] for more info on this. 

We need to address reality; I suggest there are the following options: 

1) a multipolygon for the time zone, allowing for outer and inner rings,
sharing ways with admin boundaries where appropriate, otherwise
dedicated ways with "boundary=timezone" 

2) tagging admin boundary relations with their timezone, allowing
lower-level entities to override their parent 

3) only tagging (all!) low-level entities with their timezone to avoid
the enclave problems of option 2 

This is actually conceptually similar to the problem of territorial
defaults for maxspeed and loads of other things. 

What about maritime TZ boundaries that don't correspond to an admin
boundary? 

I cannot believe it is beyond the abilities of OSM to represent time
zone areas. Of course it can be done. 

//colin 

[1] https://en.wikipedia.org/wiki/Time_in_the_United_States 

> Bye
> Frederik
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20170307/d95f48cf/attachment.html>