[Geojson] Assessing date/time ideas

[Arlo Belshee]

I would look to GeoJson to cover its domain well and integrate well into larger data systems, but not to increase its scope outside of a narrow domain. That will make it easier for people to use as part of their solution. It will also keep more uniformity in the ecosystem.

For example, time series data seems highly related. Handling full feeds does not.

If people want feeds, additional media, expiration dates, and the like, then they are probably in the realm of data, not the realm of geospatial objects. Make sure they can easily use GeoJson to describe the shapes to which their data relate, but assume they'll use something else for the rest. Not every library needs to also be an email gateway.

As an example, I work on the OData protocol. OData is a general purpose data exchange protocol. This means that we sew together various other formats and protocols to provide uniformity higher in the stack. We chose GeoJson as our format for geospatial primitives partly because it addressed one area well and did not attempt to control the entire document.

Gml was a lot less useful to us. It tries to do too much, overlaps with more things that we've already set (places we use Atom Pub), and attempts to control the whole document.

With GeoJson, we just removed everything related to features, and the rest fit very well for describing geospatial values. It's a good thing that GeoJson didn't try to solve more if the general data problem (or try to be more like a full feature service). That would have just made it harder to use to solve larger problems.

GeoJson does geospatial data well. Except for the features stuff, it doesn't provide partial solutions out of its domain. This is a great advantage. Keep it.

If people want to solve a different problem, let them use another format. If they want to use some geospatial data in that, make it easy to integrate GeoJson into that other format.

Don't try to re-invent the feed (or the RPC, the Rdbms, the service, or other things that other geospatial communities have tried to do). Instead, be like the lowly int: uniform, easy to integrate into other objects, and absolutely everywhere.

Arlo

Sent from my Windows Phone
________________________________
From: andy e
Sent: Friday, September 30, 2011 6:31 PM
To: geojson at lists.geojson.org
Subject: Re: [Geojson] Assessing date/time ideas

Maybe the ActivityStreams JSON spec can help us here?
http://activitystrea.ms/specs/json/1.0/

Anyone see an obvious way to extend ActivityStreams to include GeoJSON "sub components" (don't know what that's called)?

andy



On Fri, Sep 30, 2011 at 3:01 PM, Kristoffer Snabb <kristoffer.snabb at gmail.com<mailto:kristoffer.snabb at gmail.com>> wrote:
Hi Sean,

Expanding the domain to cover that of feeds helps,

We use GeoJSON to carry 'soft' data of perceptions and temporary data connected to a place, route or area. In this case we have been using different media to describe the context of the place and specific perceptions of a place. Anyway, we have survived with adding a property of mimetype and url but it would be nice if there existed a standard way to do this in the GeoJSON specification.

And we also expect that the perceptions of a place change over time and in that way they are created and they expire. A timestamp (feed) is also needed if we create time space diagram of routes. Although when we map daily activities of people they tend to stay many hours in one place in which case the create and expire time is again needed.

Hope this clarifies something,,

Kristoffer



2011/9/30 Sean Gillies <sean.gillies at gmail.com<mailto:sean.gillies at gmail.com>>
Time comes up in several places in the proposal fodder section of

 https://github.com/GeoJSONWG/geojson-spec/wiki/Scope

Which of these are equivalent (more or less) to the Atom/RSS notions
of a modification time stamp? Which are not? In combination with an id
(already recommended in GeoJSON) that kind of timestamp lets you sync
features between systems. With this in mind, the "adding media" bullet
suggests that some of us are looking for GeoJSON to expand its domain
to cover that of feeds. Is my assessment right?

--
Sean Gillies
_______________________________________________
Geojson mailing list
Geojson at lists.geojson.org<mailto:Geojson at lists.geojson.org>
http://lists.geojson.org/listinfo.cgi/geojson-geojson.org



--
Kristoffer Snabb
tel.+358407475576<tel:%2B358407475576>


_______________________________________________
Geojson mailing list
Geojson at lists.geojson.org<mailto:Geojson at lists.geojson.org>
http://lists.geojson.org/listinfo.cgi/geojson-geojson.org


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20111001/63885f8f/attachment.htm>