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
