Re: [Geojson] Timestamps for feature collections

[Howard Butler <[e-mail]>]

> On Dec 8, 2015, at 12:34 AM, Sean Gillies <[e-mail]> wrote:
> 
> I feel like one timestamp – not necessarily named "timestamp" and since there are a bunch of different common metadata timestamps in use (see Dublin Core, Atom, etc) a generic "timestamp" seems wrong to me – for a feature collection addresses a big issue: data archival. GeoJSON files, if saved for a number of years, will need coordinate adjustment to be used accurately. It seems to me that collections of features are going to be the kind of GeoJSON that gets archived. 

I don't see the geodesists clamoring for a GeoJSON that support time-precise coordinate precision, and using GeoJSON for that purpose seems to me to be using the wrong tool. Additionally, I think the spec is talking out both sides of its mouth to say "WGS84 most of the time is good enough for general interop, but be sure to precisely define its time epoch". 

Are future implementations supposed to make sure they apply local time corrections to data if there's timestamps? I know the language says MAY, but having only the timestamp as described in the pull request [1] is insufficient to make the transformation. An implementation that *doesn't* do it is seen as incomplete in some way. We need a lot more description than a point in time, and I think including this language sets people up for failure and frustration. 

> Could we call this timestamp "created" (as per Dublin Core) and have its semantics be that all the attributes and coordinates of the features in the collection be accurate as of that time?

Accurate to what? The most commonly used time epoch at that time? The latest one given that time? The high-precision local one? The less precise but globally available one? It's the same swamp as SRS, but worse due to the fact that there aren't as many conventions as SRSs to paper over the challenge of naming, specifying, and transforming between everything. 

If the semantics of "created" or "timestamp" or whatever really are "when this file was created" and not trying to say something about the relative time position of the coordinates, it is maybe useful sugar. However, it is scope creep to tell future GeoJSON implementors that they MAY be responsible for weakly specified coordinate time corrections, but not give them all the supporting information they need to actually do it. 

Howard

[1] https://github.com/geojson/draft-geojson/commit/2a7165d0bf844de9b412cc0827a181ebd02b1b8b#diff-1261ada59649c3fc43efdedc43f6173bR280