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
_______________________________________________
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging
