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@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/discuss
