[OSGeo-Standards] [RESTful-Policy.SWG] [OAB] Encodings and REST

[Volker Mische]

Hi Peter,

On 10/20/2012 05:40 PM, Panagiotis (Peter) A. Vretanos wrote:
> Arnulf,
> 
> I think the reasoning was that the JSON representation in the proposed 
> Geoservices standard pre-dates GeoJSON and there is already an install base 
> using that encoding.
> 
> I think this issue, however, extends beyond encodings to API's as well.  I still 
> have a hard time seeing why OGC needs 2 catalogue APIs, 2 web mapping APIs, 2 
> feature access APIs, etc ...  I think this will confuse the market.

This is also a problem I have. At the moment if you use a WMS, you are
not in a vendor lock-in there are very decent alternatives. When you
build upon the mapping part of the GeoServerives REST API, you are
locked-in (please correct me if I'm wrong).

Cheers,
  Volker


> 
> Ciao.
> 
> On 10/20/2012 08:54 AM, Arnulf Christl wrote:
> Folks,
> I neither followed the discussion closely not the decision process of
> the SWG. Can somebody summarize the rationale of the Geoservices REST
> API group for not implementing GeoJSON but going down another route?
> 
> Somehow it seems like OGC is becoming just yet another party in the
> general noise of format proliferation. We did better in other areas,
> how come we cannot stay on top of this one?
> 
> This is pretty clear language, how are we going to address it?
> https://twitter.com/vmx/status/259275792817741824
> 
> Apparently this comment by Volker Mische (who we know as supportive to
> the OGC) is receiving a lot of positive support in the broader
> geospatial IT crowd. Ignoring is not a solution.
> 
> Cheers,
> Arnulf
> 
> On 10/20/2012 12:46 PM, Peter Schut wrote:
>>>> The good thing about standards is that there are so many of them.
>>>> The bad thing about standards....
>>>>
>>>> Cheers, Peter.
>>>>
>>>>
>>>> On Fri, Oct 19, 2012 at 11:49 AM, Jeff Harrison
>>>> <jharrison at thecarbonproject.com
>>>> <mailto:jharrison at thecarbonproject.com>> wrote:
>>>>
>>>> It's my understanding that the GeoServices REST group has rejected
>>>> integrating GeoJSON.  I suppose this means that if OGC passes
>>>> GeoServices REST with its current JSON, there will then be 'OGC
>>>> GeoServices JSON'. Which means this could be added to OGC GML,
>>>> GMLsf and OGC KML on the list of encodings vendors may need to
>>>> support. Then there could be OGC GeoJSON if that angle moves
>>>> forward.  Add to this the fact that there will likely be an OSM
>>>> JSON API next year, as well potentially an OGC GeoPackage.
>>>>
>>>> So the 2013 interoperability tech landscape, for geospatial
>>>> features alone, could look like -> OGC GML, OGC GMLsf and OGC KML
>>>> ... GeoServices JSON, GeoJSON, OSM JSON, ... GeoPackage
>>>>
>>>> Is it just me, or is this a really long list?
>>>>
>>>> Regards, Jeff
>>>>
>>>>
>>>>
> 
> 
>> _______________________________________________
>> OAB mailing list
>> OAB at lists.opengeospatial.org
>> https://lists.opengeospatial.org/mailman/listinfo/oab
>>
>