[GeoJSON] GeoJSON Digest, Vol 64, Issue 3

[Jeff Yutzler]

Howard,

The temporal aspects of GML 3 suffer from the same problem as the rest of
GML 3 - waaaay too complicated. Except for specialized domains, the only
aspects of GML that have gained any semblance of traction are the ones
based on the simple features profile. GML is so unwieldy that the OGC
Moving Features SWG did not even consider it as the basis of their work.
How's that for a vote of confidence?

By "right path" I am suggesting a simple JSON encoding that mirrors the
existing GeoJSON structure. As far as I can tell, the following are needed:

   - A datetime property (adjacent to "geometry")
   - A default datetime encoding. ISO 8601[1]? Analogous to coordinate.
   (Don't touch temporal reference systems with a 10' pole.)
   - Instant, period, and sequence types (analogous to point, line, and
   multipoint, though strangely the sequence is missing from prior art such as
   ISO 19108 and GML)

This seems to cover the 80-90% case. For example, you can encode a moving
object (anything from a GPS tracker to a weather system) as a single
feature with a MultiPoint or GeometryCollection geometry and align array
indexes to the datetime instants in the time sequence.

It would take no time at all to write this up, but where it should live is
a question I can't answer.

-Jeff

[1] Note the discussion at
http://www.hanselman.com/blog/OnTheNightmareThatIsJSONDatesPlusJSONNETAndASPNETWebAPI.aspx




On Thu, Apr 3, 2014 at 8:05 PM, Howard Butler <howard at hobu.co> wrote:

>
> On Apr 3, 2014, at 1:41 PM, Jeff Yutzler <jeffy at imagemattersllc.com>
> wrote:
>
> > Howard,
> > > strong case about why it is in scope for GeoJSON
> > Some stuff changes its geometry over time and I want a
> consistent/interoperable way to encode that.
>
> A quick google showed Ron talking about time in GML [1]. Was that what was
> implemented? Has it been successful? Has it been widely used and supported?
> Has history shown the approach to be deficient in any serious way? Is a
> simple JSON encoding of that approach sufficient?
>
> >
> > > to place the burden of it on all implementors of GeoJSON
> > I don't want to burden anyone either which is why I support a
> core/extensions model. If you guys aren't willing to entertain that then
> this is probably the wrong forum.
>
> So what to do about time as a blessed extension, rather than a core
> feature, correct?
>
> >
> > > already done, widely accepted, and frequently implemented and say "use
> that"
> > I am not aware of anything that does for "when" what GeoJSON does for
> "where" nor am I aware of any initiative that is on the right path to doing
> so.
>
> Is there a right path, or is it a matter of just settling on something and
> pointing people to use it?
>
>
> On Apr 3, 2014, at 1:49 PM, Martin Daly <Martin.Daly at cadcorp.com> wrote:
>
> > I'm not against adding time per se, but I don't like the precedent being
> "Yes" instead of "No". That way lies GML 3.
>
> I agree that this default stance has served GeoJSON rather well. We had
> multiple opportunities to "fix" GeoJSON just as its adoption was sweeping
> up, probably toasting the ecosystem's interop in the process, and I think
> it's been a good thing that we've been obstinate. We all bitch about
> shapefile, but the property of it never really being able to change was a
> stabilizing force that allowed the previous generation to sprout, despite
> its obvious deficiencies. GeoTIFF too. All three beg the question of
> whether or not "don't break it" actually means "don't ever change". I don't
> know the answer to that, but history is instructive.
>
> [1] http://www.galdosinc.com/archives/151




-- 
Jeff Yutzler
Image Matters LLC
Mobile: (703) 981-8753
Office: (703) 428-6731
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geojson.org/pipermail/geojson-geojson.org/attachments/20140404/42265adf/attachment.htm>