I think this idea is a winner. We have geometry for the tricky cases but this can just fall through to the administrative geometry in places such as Arizona outside the reservations.
-- Andrew ________________________________ From: Wolfgang Zenker <wolfg...@lyxys.ka.sub.org> Sent: 07 March 2017 10:38:01 To: Tag discussion, strategy and related tools Subject: Re: [Tagging] Mapping time zones as geometries (relations) Hi, * Colin Smale <colin.sm...@xs4all.nl> [170307 09:04]: > [..] > 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? As we have seen in this discussion so far, timezones in international waters are kind of meaningless or undefined. > I cannot believe it is beyond the abilities of OSM to represent time > zone areas. Of course it can be done. the question is not if OSM can represent timezones, rather if it should and if so, in which way to do it. Following the discussion so far it looks to me like we have a rough consensus that the geographical extend of timezones should be in OSM data. I suggest following the principle of using the simplest solution that can probably work. To me that would mean to follow your suggested option number 2 whereever possible and in the (rare) cases where it is not, to create multipolygons with boundary=timezone subdividing the administrative units that sit in multiple timezones. These multipolygons would be treated as lower-level entities overriding their parents. There was the argument that monstrous multipolygons spanning the length of half a continent are probably a recipe for unusable data that is constantly broken. This would to me exclude your option 1. Your option 3 appears to require loads and loads of redundant data that will be permanently incomplete; I would try to avoid this. Wolfgang _______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
_______________________________________________ Tagging mailing list Tagging@openstreetmap.org https://lists.openstreetmap.org/listinfo/tagging
