<div dir="ltr">Howard,<div><br></div><div>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?</div>
<div><br></div><div>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:</div><div><ul><li>A datetime property (adjacent to "geometry")</li>
<li>A default datetime encoding. ISO 8601[1]? Analogous to coordinate. (Don't touch temporal reference systems with a 10' pole.)</li><li>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) </li>
</ul></div><div>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.</div>
<div><br></div><div>It would take no time at all to write this up, but where it should live is a question I can't answer.</div><div><br></div><div>-Jeff</div><div><br></div><div>[1] Note the discussion at <a href="http://www.hanselman.com/blog/OnTheNightmareThatIsJSONDatesPlusJSONNETAndASPNETWebAPI.aspx">http://www.hanselman.com/blog/OnTheNightmareThatIsJSONDatesPlusJSONNETAndASPNETWebAPI.aspx</a></div>
<div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Apr 3, 2014 at 8:05 PM, Howard Butler <span dir="ltr"><<a href="mailto:howard@hobu.co" target="_blank">howard@hobu.co</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
On Apr 3, 2014, at 1:41 PM, Jeff Yutzler <<a href="mailto:jeffy@imagemattersllc.com">jeffy@imagemattersllc.com</a>> wrote:<br>
<br>
> Howard,<br>
> > strong case about why it is in scope for GeoJSON<br>
> Some stuff changes its geometry over time and I want a consistent/interoperable way to encode that.<br>
<br>
</div>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?<br>

<div class=""><br>
><br>
> > to place the burden of it on all implementors of GeoJSON<br>
> 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.<br>
<br>
</div>So what to do about time as a blessed extension, rather than a core feature, correct?<br>
<div class=""><br>
><br>
> > already done, widely accepted, and frequently implemented and say "use that"<br>
> 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.<br>
<br>
</div>Is there a right path, or is it a matter of just settling on something and pointing people to use it?<br>
<br>
<br>
On Apr 3, 2014, at 1:49 PM, Martin Daly <<a href="mailto:Martin.Daly@cadcorp.com">Martin.Daly@cadcorp.com</a>> wrote:<br>
<br>
> 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.<br>
<br>
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.<br>

<br>
[1] <a href="http://www.galdosinc.com/archives/151" target="_blank">http://www.galdosinc.com/archives/151</a></blockquote></div><br><br clear="all"><div><br></div>-- <br>Jeff Yutzler<br>Image Matters LLC<br>Mobile: (703) 981-8753<br>
Office: (703) 428-6731<br>
</div>