Guy Harris wrote:
On Sep 3, 2013, at 4:43 AM, Lester Caine <lester@lsces.co.uk> wrote:
Stephen Colebourne wrote:
We're a lot further forward now to regaining stability, but there are a few points still outstanding.
1) Should there be one zone ID in the main files (not "backward") for each inhabited ISO-3166 code?
I've argued for this as a reinstatement of a rule of 16 years standing which is no more than common sense. Paul has argued against.
A debate on openstreetmap at the moment relates to the status of historic information in that database. Many people feel that if it does not currently exist on the ground, then it should be removed. It is a little of an academic discussion since the data will remain in the change logs anyway, but it's access to that data which is at question. The current proposal is that some data is archived to an openhistorymap which will allow the use of a 'date' to define what data is displayed, but in many cases the bulk of the main database needs to be combined with the small amount of history to create the final dataset anyway, so openhistorymap has to have a complete copy of the main map! You can't define a reason for NOT including something in the historic map.
Not to dissimilar to what we are talking about here?
You're talking about historical data, so you're presumably referring to this point in Stephen's message:
5) Pre-1970 data Some of this seems uncontroversial at this point (don't remove data, don't create new IDs just for pre-1970). Some of it is still under discussion. Only enhancement of existing IDs is necessary to the applications I work with.
As noted in the other thread, removing IDs that only differ in LMT is harder than initially thought, as the start of fixed offsets and the name of fixed offsets are pieces of data covered under the no deletion rule. As such, it is unlikely that there are many possibilities for merging zones.
not to the quoted point, which was about ISO 3166 country codes. If, for example, you're talking about rules within the UK, those all correspond to a single ISO 3166 country code, so his point about ISO 3166 country codes doesn't apply.
The I was not talking about any particular statement, but the generality of removing older data from a system that is in active use. Many of the comments relate to winnowing old data and essentially ignoring the historic material. I on the other hand would prefer to be able to retain the pre-1970 material in a format that can be used in exactly the same way as any other time window. I'm not sure as yet that we have agreement on exactly what historic data is fundamentally correct and what needs winnowing simply because it IS on shaky assumptions? The data that I've reviewed confirms what I had already assumed and is valid back to the 1880's and I think there has been a similar statement relating to US data? I've already outlined what I think is a good compromise to bring in LMT information without adding extra zones, along with the maintaining of extra pre-1970 data which just creates additional zones for just a short period of time. I'm just not sure anybody agrees with my analysis? A system that returns a list of timezones based on a supplied date would seem to me to simplify everything without loosing the critical historic zones? And move far enough back we just use LMT (or solar time) based on longitude ... -- 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