[OSGeo-Standards] Open Letter to state concerns about Geoservices REST API

Tue May 7 15:54:49 PDT 2013

I agree with Jeroen's suggestion that we should write an Open Letter to 
the OGC collating our concern.

I've started a wiki page to collate this here:
http://wiki.osgeo.org/wiki/Geoservices_REST_API#Open_Letter_to_OGC_and_voting_members

--
/We, the undersigned, have concerns that approving the "Geoservices REST 
API" as an OGC standard, would have detrimental impacts on 
interoperability within the spatial industry.//
//We strongly urge that the proposed standard be rejected in its current 
form.//
//People have listed different reasons for concern. They are described 
below.
Signed: ...
/--

I invite all to add their name to this page.
There has also been a great depth of analysis and comment on this osgeo 
discuss list over the last few days, and I suggest that we capture these 
comments under the "Concerns" heading in this wiki.

On 8/05/2013 7:10 AM, Jeroen Ticheler wrote:
> Thanks for sharing that Cameron and others!
>
> I suggest we as OSGeo (The board? Project officers/chairs of OSGeo projects?) write a letter in support of the one reflected below. It makes perfect sense to me and will hopefully strengthen their call for action.
>
> Jeroen
>
> Jeroen Ticheler
> GeoCat bv
> Veenderweg 13
> 6721 WD Bennekom
> Tel: +31 (0)6 81286572
> http://geocat.net
>
> Op 7 mei 2013 om 22:53 heeft Cameron Shorter <cameron.shorter at gmail.com> het volgende geschreven:
>
>> It seems this email from Edric Keighan to osgeo discuss must have bounced as he was not subscribed (or maybe due to having an attachment).
>>
>> On 8/05/2013 3:27 AM, Edric Keighan <ekeighan AT cubewerx com> wrote:
>>> Dear All;
>>>
>>> We have been following with a lot of interest numerous emails exchanged between OSGeo members and others regarding the positioning of OSGeo vis-a-vis the proposed OGC GeoServices REST API. This email is just to inform you that an opposition is also building up within the OGC membership community and the attached letter has been sent to all OGC TC voters who have not yet exercised their vote. People in OGC and outside of OGC deserve to know the impact of such standard on the future of OGC. It is our hope that a larger opposition will be forming and solutions developed to meet the obvious needs for interoperability in our industry.
>>>
>>> Regards,
>>>
>>> Edric Keighan - CubeWerx Inc.
>>>
>>> On behalf of:
>>> Cameron Shorter - LISASoft.
>>> Ron Lake - Galdos Systems Inc.
>>> Martin Daly - Cadcorp Ltd.
>>> Barry O'Rourke - Compusult Limited.
>> Original letter was in PDF, I've copied into text to make it easier for archiving. ...
>>
>> The OGC Interoperability
>> Movement Team Leaders
>>
>> To: All OGC members
>>
>> May 6, 2013
>>
>> Re: Is OGC losing its Way?
>>
>> Dear OGC Member,
>> This is to inform you that an important OGC event deserves your immediate attention. This note is in reference to a vote that is taking place at OGC on a proposed specification named "OGC GeoServices REST API". If approved, it will have costly, far reaching, negative impacts on interoperability, and significantly tarnish the OGC’s reputation as a champion of interoperability.
>>
>> During the last 15 years or so, we all have benefited from the collaborative effort of a large number of public and private organizations around the world to resolve numerous interoperability problems that have plagued our industry for many years. This has been an impressive achievement! But this movement will come to an end with the adoption of the proposed OGC GeoServices REST API.
>>
>> The voting process has already started and we recommend that you add your NO vote to the list of OGC voters that already expressed their clear opposition to this standard.
>>
>> While there is indeed support for RESTbased API ‘s in the geospatial community, REST is no more than a particular architectural style and should not be instantiated as a separate set of specifications as proposed by the "OGC GeoServices REST API". If the OGC community perceives a need for a REST style, then that should be developed in a general way (i.e. applicable to all OGC services) from the existing services. Note that a REST version of OGC WMTS exists and an OGC WFS version is currently being developed as part of OGC WFS 2.5 activities.
>>
>> It is important that any REST API be general in nature and not bound to specific software tools such as Flex and Silverlight.
>>
>> The proposed GeoServices REST API specification will create an immense amount of confusion in the marketplace that is not good for OGC, or for its mission of interoperability. For example, if this passes, OGC will have two RESTbased feature services and two RESTbased map services which are incompatible with one another. And soon after there will be duplicate REST implementations for all current OGC web service specifications. One solution to the confusion would be to just drop existing OGC services, or let the marketplace decide. In either case, there is then little need for the OGC as an active and innovative body to solve interoperability and information infrastructure problems.
>>
>> If your organization is one that supports the activities and mission of the OGC, and believes that interoperable interfaces and encodings can be developed through a communitybased consensus process, then you need to look at the issues, make up your mind, and vote. This is not a time for complacency.
>>
>> It is our hope that the arguments below will convince you to support an already well entrenched interoperability movement at OGC:
>>
>> * We see no viable outcomes and benefits to OGC members in rubberstamping software products if this will result in creating more interoperability problems.
>>
>> * We believe that ‘rubber stamping’ existing software from a single vendor is unfair and anti-competitive, and not appropriate for OGC. This will only create an environment where the vendor with the deepest pockets wins to the detriments of all other players in the industry.
>>
>> * The proposed GeoServices REST API specification overlaps with most OGC standards already deployed by many organizations across the world: WMS, WMTS, WCS, WFS, SE/SLD, CS/W.
>>
>> * There are no needs for OGC to support duplicate standards that perform the same functionality; this does not make sense.
>>
>> * In the eventuality that the GeoServices REST API is adopted, all organizations in the industry will have to bear extra costs for purchasing two sets of OGC standard products since they will not interoperate.
>>
>> So, if you are like us, strong supporters of OGC’s stated goal of interoperability, the liberalisation of spatial data in ways that provide equal opportunities for all industry participants, small and large including the public, then you should register your NO vote today at the OGC site:
>>
>> https://portal.opengeospatial.org/index.php?m=projects&a=view&project_id=82&tab=5&subt
>> ab=0
>>
>> Best regards,
>> Edric Keighan, President & CEO CubeWerx Inc.
>> Ron Lake, CEO Galdos Systems Inc.
>> Martin Daly, Technology Director Cadcorp Ltd.
>> Camron Shorter, Geospatial Solutions Director, LISAsoft
>> Barry O’Rourke, President, Compusult Limited
>>
>>
>> -- 
>> Cameron Shorter
>> Geospatial Solutions Manager
>> Tel: +61 (0)2 8570 5050
>> Mob: +61 (0)419 142 254
>>
>> Think Globally, Fix Locally
>> Geospatial Solutions enhanced with Open Standards and Open Source
>> http://www.lisasoft.com
>>
>> _______________________________________________
>> Discuss mailing list
>> Discuss at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/discuss

-- 
Cameron Shorter
Geospatial Solutions Manager
Tel: +61 (0)2 8570 5050
Mob: +61 (0)419 142 254

Think Globally, Fix Locally
Geospatial Solutions enhanced with Open Standards and Open Source
http://www.lisasoft.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/standards/attachments/20130508/df559049/attachment.html>