[GeoJSON] GeoJSON Digest, Vol 64, Issue 1

[Mark Stosberg]

I'm new here, but from my experience managing other software related
projects, having a smaller, simpler core with extensions has worked
well.

The core and extensions can be documented or marketed as closely
related, without being technically tied together.

     Mark


On Wed, Apr 2, 2014 at 9:22 AM, Jeff Yutzler <jeffy at imagemattersllc.com> wrote:
> Karl,
> Personally I think that this is best solved with a core and extensions
> model. GeoJSON is the core, providing a basic feature and geometry model.
> TopoJSON and GeoJSON-LD are emerging as extensions and it follows that
> support for temporal properties should also be one. As Sean suggests, your
> temporal requirements are pretty advanced - many temporal applications like
> map stories would be satisfied by a simple(r) model. To me TopoTime looks
> like a further extension of a basic temporal extension.
> Regards,
> Jeff
>
>> ----------------------------------------------------------------------
>> Date: Tue, 1 Apr 2014 10:02:00 -0600
>> From: Sean Gillies <sean.gillies at gmail.com>
>> To: Karl Grossner <karlg at stanford.edu>
>> Cc: "geojson at lists.geojson.org" <geojson at lists.geojson.org>
>> Subject: Re: [GeoJSON] Time and GeoJSON, redux
>> Message-ID:
>>
>> <CAOodmJph=RzF6gh2uRr0jypzZzx4=szaWbxHF4FYD5Bphj+aQg at mail.gmail.com>
>> Content-Type: text/plain; charset="iso-8859-1"
>>
>> Dear Karl,
>>
>> I worked on a little historical gazetteer project for a while and continue
>> to be very interested in time. While I'm not in favor of making time part
>> of the GeoJSON core, I think it would be a cool application for
>> GeoJSON-LD.
>>
>> I don't agree that CIDOC-CRM or Topotime white papers are good starting
>> points for this discussion. Rather, I think the right starting points are:
>>
>>   1. The frequently asked question "how do I represent time series and/or
>> GPX data in GeoJSON?"
>>   2. How can we extend GeoJSON so that "story map" applications (such as
>> http://storymap.knightlab.com/) are simple to develop and so that this
>> kind
>> of data can benefit from the ecosystem around GeoJSON (Leaflet, GitHub
>> support, etc.
>>
>> Fuzzy dates and historical calender system bugs complicate the latter,
>> certainly, and I feel that GeoJSON should avoid fuzzy dates as it avoids
>> fuzzy locations. Also, the choice of a standard temporal reference system
>> will be interesting.
>>
>>
>>
>> On Fri, Mar 28, 2014 at 3:13 PM, Karl Grossner <karlg at stanford.edu> wrote:
>>
>> > At least three efforts at developing standard representations of
>> > explicitly temporal objects have begun and are in an early stage of
>> > development: Topotime [1], the CRMgeo extension to CIDOC-CRM [2], and
>> > the
>> > nascent PeriodO [3]. All of these view temporal objects as inherently
>> > spatial and vice-versa. Gazetteer-related projects including Pelagios 3
>> > [4], which is developing an "index of toponyms attested," will have some
>> > standardized form of representing attested temporal dimensions of a
>> > toponym
>> > and/or its referrent feature.
>> >
>> > GeoJSON is an important standard for representing geographic features,
>> > but
>> > the specification does not address temporality explicitly. My view is
>> > that
>> > it should, going forward. At present, temporal attributes of a feature
>> > can
>> > be added as a property, but isn't the temporal extent of a feature
>> > co-equal
>> > as a descriptor with its spatial extent? Software can be written (and
>> > is)
>> > to parse values from ad hoc "properties" : { ... }, but will it be
>> > useful
>> > to elevate temporal description to the level of "geometry" in the
>> > standard?
>> >
>> > As a co-developer of Topotime, engaged in collaborative discussions with
>> > some of the other projects mentioned here, I'd like to start a
>> > discussion
>> > here of how such spatial-temporal representations can or should relate
>> > to
>> > GeoJSON, and the emerging GeoJSON-LD. I've written a few further
>> > thoughts
>> > about it on a blog post [5].
>> >
>> > Thoughts?
>> >
>> > [1] http://dh.stanford.edu/topotime
>> > [2] http://www.cidoc-crm.org/docs/Technical%20Report435-CRMgeo.pdf
>> > [3] http://caa2014.sciencesconf.org/browse/author?authorid=233410
>> > [4] http://pelagios-project.blogspot.com/
>> > [5]
>> > http://kgeographer.com/wp/joining-space-and-time-in-geographic-features/
>> >
>> > +++++
>> > Karl Grossner
>> > karlg at stanford.edu
>> >
>> >
>> >
>> > _______________________________________________
>> > GeoJSON mailing list
>> > GeoJSON at lists.geojson.org
>> > http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
>> >
>> >
>>
>>
>> --
>> Sean Gillies
>> -------------- next part --------------
>> An HTML attachment was scrubbed...
>> URL:
>> <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20140401/0243d5e3/attachment.html>
>>
>> ------------------------------
>>
>> _______________________________________________
>> GeoJSON mailing list
>> GeoJSON at lists.geojson.org
>> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
>>
>>
>> End of GeoJSON Digest, Vol 64, Issue 1
>> **************************************
>
>
>
>
> --
> Jeff Yutzler
> Image Matters LLC
> Mobile: (703) 981-8753
> Office: (703) 428-6731
>
> _______________________________________________
> GeoJSON mailing list
> GeoJSON at lists.geojson.org
> http://lists.geojson.org/listinfo.cgi/geojson-geojson.org
>



-- 
    Mark Stosberg
    Senior Systems Engineer
    RideAmigos