<br><br><div class="gmail_quote">2012/10/20 Arnulf Christl <span dir="ltr"><<a href="mailto:arnulf.christl@metaspatial.net" target="_blank">arnulf.christl@metaspatial.net</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
Folks,<br>
I neither followed the discussion closely not the decision process of<br>
the SWG. Can somebody summarize the rationale of the Geoservices REST<br>
API group for not implementing GeoJSON but going down another route?<br>
<br>
Somehow it seems like OGC is becoming just yet another party in the<br>
general noise of format proliferation. We did better in other areas,<br>
how come we cannot stay on top of this one?<br>
<br>
This is pretty clear language, how are we going to address it?<br>
<a href="https://twitter.com/vmx/status/259275792817741824" target="_blank">https://twitter.com/vmx/status/259275792817741824</a><br>
<br>
Apparently this comment by Volker Mische (who we know as supportive to<br>
the OGC) is receiving a lot of positive support in the broader<br>
geospatial IT crowd. Ignoring is not a solution.<br>
<br>
Cheers,<br>
Arnulf<br>
<br>
On 10/20/2012 12:46 PM, Peter Schut wrote:<br>
> The good thing about standards is that there are so many of them.<br>
> The bad thing about standards....<br>
><br>
> Cheers, Peter.<br>
><br>
><br>
> On Fri, Oct 19, 2012 at 11:49 AM, Jeff Harrison<br>
> <<a href="mailto:jharrison@thecarbonproject.com">jharrison@thecarbonproject.com</a><br>
> <mailto:<a href="mailto:jharrison@thecarbonproject.com">jharrison@thecarbonproject.com</a>>> wrote:<br>
><br>
> It's my understanding that the GeoServices REST group has rejected<br>
> integrating GeoJSON.  I suppose this means that if OGC passes<br>
> GeoServices REST with its current JSON, there will then be 'OGC<br>
> GeoServices JSON'. Which means this could be added to OGC GML,<br>
> GMLsf and OGC KML on the list of encodings vendors may need to<br>
> support. Then there could be OGC GeoJSON if that angle moves<br>
> forward.  Add to this the fact that there will likely be an OSM<br>
> JSON API next year, as well potentially an OGC GeoPackage.<br>
><br>
> So the 2013 interoperability tech landscape, for geospatial<br>
> features alone, could look like -> OGC GML, OGC GMLsf and OGC KML<br>
> ... GeoServices JSON, GeoJSON, OSM JSON, ... GeoPackage<br>
><br>
> Is it just me, or is this a really long list?<br>
><br>
> Regards, Jeff<br>
><br>
><br>
><br>
<br>
<br>
- --<br>
Arnulf Christl<br>
<a href="http://metaspatial.net" target="_blank">http://metaspatial.net</a><br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.11 (GNU/Linux)<br>
Comment: Using GnuPG with Mozilla - <a href="http://www.enigmail.net/" target="_blank">http://www.enigmail.net/</a><br>
<br>
iEYEARECAAYFAlCCnwkACgkQXmFKW+BJ1b0XIwCaA4Yx4CwzDf3Ti2YTbhk+1MGE<br>
TiEAn1mOMiraT+VAyYWgO9RtiFkKmqxq<br>
=UFEF<br>
-----END PGP SIGNATURE-----<br>
_______________________________________________<br>
Standards mailing list<br>
<a href="mailto:Standards@lists.osgeo.org">Standards@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/standards" target="_blank">http://lists.osgeo.org/mailman/listinfo/standards</a><br>
</blockquote></div><br>