Difference between revisions of "Geoservices REST API"

From OSGeo
Jump to navigation Jump to search
 
(141 intermediate revisions by 75 users not shown)
Line 1: Line 1:
This wiki page aims to collate community concerns related to the adoption of the "Geoservices REST API" document as a standard of the [http://www.opengeospatial.org/ Open Geospatial Consortium (OGC)]. The page is being collaboratively edited, targeting completion by Wednesday 15 May 2013, after which it will be delivered by the board of the [http://osgeo.org OSGeo Foundation (OSGeo)] to the OGC and OGC voting members.
+
This page aims to collate community concerns related to the adoption of the "Geoservices REST API" document as a standard of the [http://www.opengeospatial.org/ Open Geospatial Consortium (OGC)]. The page has been collaboratively edited, and delivered by the board of the [http://osgeo.org OSGeo Foundation (OSGeo)] to the OGC and OGC voting members on Friday 17 May 2013.
 +
 
 +
The version of the document delivered can be found here: http://wiki.osgeo.org/index.php?title=Geoservices_REST_API&oldid=71311
  
 
= Cover Letter from the OSGeo Board =
 
= Cover Letter from the OSGeo Board =
''Please don't edit this "Cover Letter" statement, which has been approved by the OSGeo Board.''
 
  
The board of the [http://osgeo.org Open Source Geospatial Foundation] (OSGeo) is presenting this letter to the OGC. It highlights concerns about the "GeoServices REST API" from many people within the OSGeo community. As always, if there is anything the OSGeo board can do to help, then please let us know.
+
The board of the [http://osgeo.org Open Source Geospatial Foundation] (OSGeo) is presenting this letter to the OGC. The letter highlights concerns about the "GeoServices REST API" from many people within the OSGeo community. As always, if there is anything the OSGeo board can do to help, then please let us know.
  
 
Signed: Jeff McKenna (OSGeo president),  
 
Signed: Jeff McKenna (OSGeo president),  
Line 17: Line 18:
  
 
= Open Letter to OGC and voting members =
 
= Open Letter to OGC and voting members =
 
''Please don't edit this "Open Letter" statement, comments and discussion should go in the "Further Concerns" section below.''
 
  
 
May 2013
 
May 2013
  
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, the undersigned, have concerns that approving the "Geoservices REST API" as an OGC standard, will have detrimental impacts on interoperability within the spatial industry.
  
 
We strongly urge that the proposed "Geoservices REST API", as it stands in May 2013, be rejected as an OGC standard.
 
We strongly urge that the proposed "Geoservices REST API", as it stands in May 2013, be rejected as an OGC standard.
  
People have listed different reasons for concern. They are described below.
+
People have listed different reasons for concern. These concerns are described below.
  
 
== Signed ==
 
== Signed ==
''Please add your name here if you agree with the above statement. Include name, work title (if appropriate), very brief title/involvement in OSGeo if appropriate. (Link to OSGeo profile if appropriate). You may sign as a group, such as the Project Steering Committee of XXX project if you wish, or as Your Name on behalf of YYY company.''
 
  
 
# [[User:camerons|Cameron Shorter]], Geospatial Solutions Director at [http://lisasoft.com LISAsoft], core contributor & coordinator of [http://live.osgeo.org OSGeo-Live], OSGeo Board member
 
# [[User:camerons|Cameron Shorter]], Geospatial Solutions Director at [http://lisasoft.com LISAsoft], core contributor & coordinator of [http://live.osgeo.org OSGeo-Live], OSGeo Board member
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal Scientist for RadiantBlue Technologies Inc.
+
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Principal Scientist for RadiantBlue Technologies Inc.
 
# [[User:Woodbri|Stephen Woodbridge]], Director of [http://imaptools.com iMaptools.com], Contributor and/or PSC of [http://mapserver.org Mapserver], [http://pgrouting.org/ pgRouting], [http://www.pagcgeo.org/ PAGC], and [http://www.postgis.org/ PostGIS]
 
# [[User:Woodbri|Stephen Woodbridge]], Director of [http://imaptools.com iMaptools.com], Contributor and/or PSC of [http://mapserver.org Mapserver], [http://pgrouting.org/ pgRouting], [http://www.pagcgeo.org/ PAGC], and [http://www.postgis.org/ PostGIS]
 
# [[User:rouault|Even Rouault]], Geospatial developer, OSGeo Charter Member, core contributor and PSC member of [http://gdal.org GDAL/OGR], contributor of [http://mapserver.org Mapserver], [http://trac.osgeo.org/proj/ PROJ.4], [http://trac.osgeo.org/geotiff/ libgeotiff], [http://shapelib.maptools.org/ shapelib], [http://www.remotesensing.org/libtiff/ libtiff]
 
# [[User:rouault|Even Rouault]], Geospatial developer, OSGeo Charter Member, core contributor and PSC member of [http://gdal.org GDAL/OGR], contributor of [http://mapserver.org Mapserver], [http://trac.osgeo.org/proj/ PROJ.4], [http://trac.osgeo.org/geotiff/ libgeotiff], [http://shapelib.maptools.org/ shapelib], [http://www.remotesensing.org/libtiff/ libtiff]
Line 42: Line 40:
 
# [[User:milovanderlinden|Milo van der Linden]], member at [http://www.opengeogroep.nl OpenGeoGroep]
 
# [[User:milovanderlinden|Milo van der Linden]], member at [http://www.opengeogroep.nl OpenGeoGroep]
 
# [[User:surveyor|Landon Blake]], GIS Department Manager/Land Surveyor at [http://www.ksninc.com KSN], OSGeo California Chapter Board Representative.
 
# [[User:surveyor|Landon Blake]], GIS Department Manager/Land Surveyor at [http://www.ksninc.com KSN], OSGeo California Chapter Board Representative.
# [[User:dmorissette|Daniel Morissette]], President at [http://mapgears.com/ Mapgears], core contributor and PSC member of [http://mapserver.org Mapserver] and [http://gdal.org GDAL/OGR]. Former OGC TC member and involved in the implementation of several OGC WxS services specs in MapServer.
+
# [[User:dmorissette|Daniel Morissette]], President at [http://mapgears.com/ Mapgears], OSGeo Board member, core contributor and PSC member of [http://mapserver.org Mapserver] and [http://gdal.org GDAL/OGR]. Former OGC TC member and involved in the implementation of several OGC WxS specs in MapServer.
 
# [[User:blammo|Bob Basques]], GIS Systems Developer at the City of Saint Paul, MN. [http://gis.ci.stpaul.mn.us Public Works GIS (GISmo)], Technical Director at [http://www.sharedgeo.org SharedGeo], OSGeo Charter Member, OSGeo TCMUG local chapter member, Co-founder and PSC member of [http://www.geomoose.org GeoMoose] project.
 
# [[User:blammo|Bob Basques]], GIS Systems Developer at the City of Saint Paul, MN. [http://gis.ci.stpaul.mn.us Public Works GIS (GISmo)], Technical Director at [http://www.sharedgeo.org SharedGeo], OSGeo Charter Member, OSGeo TCMUG local chapter member, Co-founder and PSC member of [http://www.geomoose.org GeoMoose] project.
 
# [[User:vehrka|Pedro-Juan Ferrer Matoses]], PM at Omnium Strategic Intelligence, Spain, OSGeo Charter Member, OSGeo Spanish Local Chapter Liaison officer.
 
# [[User:vehrka|Pedro-Juan Ferrer Matoses]], PM at Omnium Strategic Intelligence, Spain, OSGeo Charter Member, OSGeo Spanish Local Chapter Liaison officer.
Line 86: Line 84:
 
# [[User:rbraam | Roy Braam]], Software Engineer @ [http://www.b3partners.nl | B3Partners]
 
# [[User:rbraam | Roy Braam]], Software Engineer @ [http://www.b3partners.nl | B3Partners]
 
# [[User:peteris | Peteris Bruns]], Latvia, GIS Consultant & Software Engineer @ [http://www.sungis.lv | SunGIS]
 
# [[User:peteris | Peteris Bruns]], Latvia, GIS Consultant & Software Engineer @ [http://www.sungis.lv | SunGIS]
# [[User:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
+
# [[User:Lutra | Giovanni Manghi]], Portugal, [http://www.naturalgis.pt/ NaturalGIS], OSGeo member, OSGeo-Portugal
 
# [[User:Hfpmartins | Hugo Martins]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], WebGIS Developer, OSGeo-Portugal Member
 
# [[User:Hfpmartins | Hugo Martins]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], WebGIS Developer, OSGeo-Portugal Member
 
# [[User:Sabb | Saber Razmjooei]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
 
# [[User:Sabb | Saber Razmjooei]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
Line 100: Line 98:
 
# [[Santiago Higuera]], CEO at [http://Mercatorlab.com Mercatorlab], OSGeo Spanish Local Chapter Board Member, Spain
 
# [[Santiago Higuera]], CEO at [http://Mercatorlab.com Mercatorlab], OSGeo Spanish Local Chapter Board Member, Spain
 
# [[Alan Boudreault]], Developer at [http://mapgears.com/ Mapgears], contributor to [http://mapserver.org Mapserver] and [http://gdal.org GDAL/OGR].
 
# [[Alan Boudreault]], Developer at [http://mapgears.com/ Mapgears], contributor to [http://mapserver.org Mapserver] and [http://gdal.org GDAL/OGR].
 +
# [[User:mikesaunt|Mike Saunt]], UK, Owner at [http://astuntechnology.com Astun Technology Ltd], OSGeo sponsor
 +
# [[User:msmitherdc|Michael Smith]], OSGeo Charter Member, Physical Scientist US Army Corps of Engineers Remote Sensing GIS Center
 +
# [[User:Kalxas|Angelos Tzotsos]], OSGeo Charter Member, Researcher at National Technical University of Athens
 +
# [[User:Kimaidou|Michaël Douchin]], France, GIS consultant & software engineer at [http://3liz.com/ 3liz]
 +
# [[User:PedroVenancio | Pedro Venâncio]], Portugal, GIS Analyst @ Municipality of Pinhel
 +
# [[User:Jgrocha|Jorge Gustavo Rocha]], Portugal, GIS Professor at Universidade do Minho
 +
# [[User:Danielkastl| Daniel Kastl]], Japan, [http://georepublic.info Georepublic], Founder
 +
# [[Diodata|John Callahan]], US, Research Scientist and GIS/Remote Sensing Specialist, University of Delaware
 +
# [[User:kjkalyan|Kalyan Janakiraman]], Senior Systems Analyst, Business Development Services, NSW Land and Property Information, Sydney, Australia
 +
# [[User:goliadranger|Phillip Davis]], Director, National Geospatial Technology Center of Excellence, Texas, USA
 +
# [[User:simonp|Simon Pigot]], contributor to and PSC member of [http://geonetwork-opensource.org GeoNetwork opensource] (speaking for myself, not an official view of my employer)
 +
# [[User:jbryant|John Bryant]], Consultant, Mammoth Mapping, Dawson City, Canada and GIS/DB Admin, Jupiter Mines, Perth, Australia
 +
# [[ChIossif|Christos Iossifides]], Remote Sensing Instructor, Laboratory Teaching Staff, Remote Sensing Instructor and Researcher, National Technical University of Athens
 +
# [[User:tbowden|Tim Bowden]], Spatial Consultant, Perth, Australia
 +
# [[User:Lucadelu|Luca Delucchi]], GIS Technician, Trento, Italy
 +
# [[User:bartvde|Bart van den Eijnden]], GIS software developer, Utrecht, Netherlands
 +
# [[User:eyedol|Henry Addo]], Software Developer at Ushahidi [http://ushahidi.com], contributor of [http://live.osgeo.org OSGeo-Live]
 +
# [[User:iacovellas|Stefano Iacovella]], GIS consultant & software engineer, Rome, Italy
 +
# [[User:Mtoonen| Meine Toonen]], Software Engineer @ [http://www.b3partners.nl B3Partners], The Netherlands
 +
# [[User:arneke| Arne Kepp]], Software Engineer, Oslo, Norway
 +
# [[User:Pirmin_Kalberer| Pirmin Kalberer]], Managing director [http://sourcepole.com/ Sourcepole], [http://fossgis.de FOSSGIS] member, Contributor of [http://gdal.org GDAL/OGR], [http://qgis.org QGIS], [http://mapfish.org/ Mapfish], [https://wiki.ubuntu.com/UbuntuGIS UbuntuGIS], [http://live.osgeo.org OSGeo-Live], Switzerland
 +
# [[User:hdus| Dr. Horst Düster]], Managing director [http://sourcepole.com/ Sourcepole], [http://fossgis.de FOSSGIS] member, QGIS Project Treasurer and Contributor of [http://qgis.org QGIS], Zürich, Switzerland
 +
# [[Richard_Duivenvoorde| Richard Duivenvoorde]], Managing director & software developer [http://www.webmapper.net/ Webmapper], QGIS community member
 +
# [[User:stevenfeldman|Steven Feldman]], Principal at [http://knowwhereconslting.co.uk KnowWhere Consulting] and Chair of the LOC for [http://2013.foss4g.org/ FOSS4G 2013]
 +
# [[Edward_Mac_Gillavry| Edward Mac Gillavry]], Managing director & software developer [http://www.webmapper.net/ Webmapper]
 +
# [[User:maximdubinin| Maxim Dubinin]], CEO at [http://www.nextgis.org/ NextGIS], head of [http://gis-lab.info GIS-Lab.info]
 +
# [[User:flavour| Fran Boon]], PMC Chair at [http://sahanafoundation.org/ Sahana Foundation], CTO of [http://aidiq.com AidIQ]
 +
# [[User:Ian| Ian Edwards]], Chair [http://www.osgeo.org/uk OSGeo:UK]
 +
# [[User:Bishop|Dmitriy Baryshnikov]] Developer at [http://www.nextgis.org/ NextGIS], [http://gdal.org GDAL/OGR] committer, [http://wxgis.googlecode.com wxGIS] developer, [http://gis-lab.info GIS-Lab.info] community member
 +
# [[User:cvanlith| Chris van Lith]], Director [http://www.b3partners.nl B3Partners], member of [http://www.opengeogroep.nl OpenGeoGroep]
 +
# [[User:VincentP| Vincent Picavet]], co-founder of [http://www.oslandia.com Oslandia], founding member and treasurer of OSGeo-FR
 +
# [[User:Stefan_A._Tzeggai| Stefan A. Tzeggai]], creator of [http://www.geopublishing.org/AtlasStyler AtlasStyler SLD editor], founder of [http://www.empirica-systeme.de empirica systeme gmbh]
 +
# [[User:Rdewit| Roald de Wit]], Geospatial Software Engineer, Melbourne, Australia
 +
# [[User:grizonnetm| Manuel Grizonnet]], working at the [http://www.cnes.fr/ French Space Agency],  [http://www.orfeo-toolbox.org/otb/ ORFEO ToolBox library] developer
 +
# [[User:RdeMoritoru| Toru Mori]], President & CEO, [http://www.orkney.co.jp Orkney, Inc.], Yokohama, Japan, Representative of OSGeo Japan Chapter, OSGeo Charter Member
 +
# [[User:MarkusSchneider2|Markus Schneider]], TMC chair of the [http://www.deegree.org deegree project], CEO of [http://www.occamlabs.de Occam Labs]
 +
# [[User:elena|Elena Mezzini]], Remote Sensing and GIS Technician, GFOSS.it member, Bologna, Italy
 +
# [[User:Alexbruy|Alexander Bruy]], [http://nextgis.org NextGIS], QGIS core developer
 +
# [[User:Dfurtado | Danilo Furtado]], Portugal, OSGeo member, OSGeo-Portugal
 +
# [[User:Stranger | Andreas Schmitz]], Germany, deegree core developer and TMC member, CTO of [http://www.occamlabs.de Occam Labs]
 +
# [[User:Olt | Oliver Tonnhofer]], Germany, [http://mapproxy.org MapProxy] core developer, founder & CTO of [http://www.omniscale.com Omniscale]
 +
# [[User:Thomas_Baschetti | Thomas Baschetti]], Germany, Freelancer, Mapbender PSC Member, [http://fossgis.de FOSSGIS] member
 +
# [[User:IanMayo | Ian Mayo]], GeoSpatial developer, UK
 +
# [[User:imincik | Ivan Mincik]], CEO of [http://www.gista.sk GISTA s.r.o.], Slovakia
 +
# [[User:edmar.moretti | Edmar Moretti]], Software developer, [http://www.i3geo.com i3GEO] core developer, Brazil
 +
# [[User:Moreira | Diego Moreira]], GIS Analyst, Contributor of [http://qgis.org QGIS], Brazil
 +
# [[User:Ginetto | Luigi Pirelli]], Freelance Analyst/Programmer, co-founder of Italian OSGEO Local Chapter [http://www.gfoss.it GFOSS.it], Italy
 +
# [[User:kyle | Kyle Shannon]] Software Developer, contributor of [http://gdal.org GDAL/OGR], United States
 +
# [[User:DMateos | David Mateos]], worker-owner at [http://www.terrativa.net Terrativa S. Coop.] and OSGeo Spanish Local Chapter Member, Spain
 +
# [[Luis Franco]], researcher and GIS analyst at the University of Santiago de Compostela, Spain
 +
# [[User:groldan | Gabriel Roldan]], Software Developer, Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Member
 +
# [[User:kotzino | Dimitris Kotzinos]], OSGEO Charter Member, OSGEO Greek Chapter founder, Assistant Professor TEI of Serres, Greece
 +
# [[User:Perriger|Stefan Steiniger]], owner of [http://www.geosteiniger.cl GEO Steiniger Ltda.], contributor to [http://openjump.org OpenJUMP GIS] and [http://www.opentripplanner.org OpenTripPlanner] and author of several FOSS4G overview articles, Canada/Chile
 +
# [[User:Iwasaki | Nobusuke Iwasaki]], Senior Researcher, National Institute for Agro-Environmental Sciences, Tsukuba, Japan, OSGeo Japan Chapter Board Member
 +
# [[User:Johnson | Ross Johnson]], Land Information Officer, City of Ryde Council and NSW Committee member of Surveying & Spatial Sciences Institute (SSSI)
 +
# [[User:kumaran |Kumaran Narayanaswamy]], CEO & Managing Director of kCube Consultancy Services Pvt Ltd India.[http://www.kcubeconsulting.com], Member of India OSGeo Chapter.
 +
# [[User:luis |Luis Fernando Bueno]], Professor at Federal University of Rondonia, researcher and GIS analyst, Brazil.
 +
# [[User:MapperBob |Bob Bruce, FEC, P.Eng.]], Geomatics Engineer, Winnipeg, Manitoba, Canada.
 +
# [[User:mlennert|Moritz Lennert]], Researcher in geography at the [http://www.ulb.ac.be/ Free University of Brussels (ULB)], [http://grass.osgeo.org GRASS-PSC]
 +
# [[User:Ianturton|Ian Turton]], Software developer and open standards advocate, [http://geotools.org GeoTools-PSC]
 +
# [[User:Djay|Gérald Fenoy]], OSGeo Charter member, Founder and CEO of GeoLabs SARL, France
 +
# [[User:bitner|David Bitner]], OSGeo Charter member, OSGeo VP for Geodata, OSGeo Twin Cities Chapter, [http://sahanafoundation.org Sahana Software Foundation] Board of Directors, [http://www.metrogis.org MetroGIS] Coordinating Committee Chair, owner [http://dbspatial.com dbSpatial]
 +
# [[User:Peter Loewe|Peter Löwe]], OSGeo Charter member, Senior Researcher at Deutsches GeoForschungsZentrum GFZ, General Manager GISIX.com
 +
# [[User:gfleming|Gavin Fleming]], OSGeo Charter member, owner of AfriSpatial.
 +
# [[User:FrankM|Frank Maes]], GeoICT professional, Head Operations at [http://www.geosparc.com Geosparc], Contributor & community member of [http://www.geomajas.org Geomajas], OSGeo member
 +
# [[User:epifanio|Massimo Di Stefano]] , OSGeo Charter Member, Italy, founder-member of OSGeo Italian Local Chapter.
 +
# [[User:capooti|Paolo Corti]], Geospatial software developer, Rome, Italy
 +
# [[User:Mlechner|Marco Lechner]], chairman [http://fossgis.de FOSSGIS e.V.] (OSGeo local chapter D-A-CH)
  
 
= Summary =
 
= Summary =
  
''Please don't edit this section - it is now locked to ensure editorial review. You may send comments to Cameron Shorter AT gmail .com''
+
The OGC candidate standard titled "GeoServices REST API" is currently, in May 2013, being considered to be approved as an Open Geospatial Consortium (OGC) standard. The vote to accept the document as a standard is unusually contentious. The controversy is the cause of this open letter.
 
 
The document titled "GeoServices REST API" is currently, in May 2013, being considered to be included as one of the Open Geospatial Consortium (OGC) standards. The vote to accept the document as a standard is unusually contentious; the controversy is the cause of this page.
 
 
 
The document was previously released for public comment and can be found [http://www.opengeospatial.org/standards/requests/89 on the request for public comment page] (though public comment has been closed for now).
 
  
The document attempts to standardize a suite of web services such as a service which provides map images, a service which provides geospatial feature data, and a service which performs geospatial processing. The standard focuses on interactions via a defined hierarchy of URLs and using predominantly a particular set of JSON schemas for the exchange of geospatial data.
+
The candidate standard was previously released for public comment and can be found [http://www.opengeospatial.org/standards/requests/89 on the request for public comment page] (though public comment has been closed for now).
  
 +
The candidate standard attempts to standardize a suite of web services such as a service which provides map images, a service which provides geospatial feature data, and a service which performs geospatial processing. The candidate standard focuses on interactions via a defined hierarchy of URLs and using predominantly a particular set of JSON schemas for the exchange of geospatial data.
  
 +
== Criticism and Response ==
  
 +
The '''criticism''' of the adoption of this particular document as an OGC Standard includes a wide variety of reasons such as:
  
The adoption of the document as an OGC Standard is contentious for a wide variety of reasons including:
+
* the OGC's process through which the document was developed which is thought to lack sufficient flexibility to respond to input from various stakeholders,  
 
 
* the process through which the document was developed which is thought to lack sufficient flexibility to respond to input from various stakeholders,  
 
 
* the focus of the document on 'REST' and 'API' which is seen as not matching the ideas others have for these concepts,
 
* the focus of the document on 'REST' and 'API' which is seen as not matching the ideas others have for these concepts,
 
* the names of the standard and of the services which are seen as potentially confusing,  
 
* the names of the standard and of the services which are seen as potentially confusing,  
Line 133: Line 196:
 
# This will result in a diminished importance of OGC, as the "OGC standards" stamp of approval will not equate interoperability.
 
# This will result in a diminished importance of OGC, as the "OGC standards" stamp of approval will not equate interoperability.
 
# After a while, in order to solve interoperability issues, a respected international organisation or program will likely take the initiative to mandate one standard as the preferred standard for all agencies to follow. To date, the OGC has provided this leadership.
 
# After a while, in order to solve interoperability issues, a respected international organisation or program will likely take the initiative to mandate one standard as the preferred standard for all agencies to follow. To date, the OGC has provided this leadership.
# One standard taking prominance over the other will likely lead to the other being neglected or deprecated, resulting in many OGC compliant systems becoming legacy systems in the process. This should be considered an undesirable outcome for a standards organisation.
+
# One standard taking prominence over the other will likely lead to the other being neglected or deprecated, resulting in many OGC compliant systems becoming legacy systems in the process. This should be considered an undesirable outcome for a standards organisation.
 
 
(The public comments on the standard should eventually be released as a publication of the OGC and may already have been. This will require further investigation.)
 
 
 
 
 
 
 
  
In response to these issues, the authors of the Geoservices REST API document have stated that:
+
In '''response''' to these issues, the authors of the Geoservices REST API document have stated that:
  
 
* the process of the OGC has been followed completely,
 
* the process of the OGC has been followed completely,
 
* the specification actually is RESTful and does define an API,
 
* the specification actually is RESTful and does define an API,
* the name, due to the controversy, may be open for modification
+
* the name, due to the controversy, is open for modification
 
* the OGC does not forbid duplication of service functionality, already has duplication between the W*S and the S*S (sensor) family of standards, should not block progress in the name of 'one true way', and harmonization between the services can be considered in the future,
 
* the OGC does not forbid duplication of service functionality, already has duplication between the W*S and the S*S (sensor) family of standards, should not block progress in the name of 'one true way', and harmonization between the services can be considered in the future,
 
* the JSON format exists and functions, and
 
* the JSON format exists and functions, and
Line 151: Line 209:
 
The authors also stress that the existence of a large user base shows the service is useful, and that the standardization of the services at the OGC may encourage new implementations.
 
The authors also stress that the existence of a large user base shows the service is useful, and that the standardization of the services at the OGC may encourage new implementations.
  
(The formal response documents prepared by the working group are in the process of being released to the public, as of early May 2013. When they are released, links to those responses will hopefully be presented here as well.)
+
The SWG has published two documents in response to various comments.
 +
* [https://portal.opengeospatial.org/files/?artifact_id=54048 OGC 12-646 Response to RFC Comments] presents the responses from the Standards Working Group to the comments received from the public during the public Request for Comments (RFC).
 +
* [https://portal.opengeospatial.org/files/?artifact_id=54049 OGC 13-031r1 Response to 'no' votes] presents the responses from the Standards Working Group to the reasons given by the organizations voting _no_ during the adoption vote.
 +
 
 +
Both are available through the links above, or via the [http://www.opengeospatial.org/projects/groups/gservrestswg public page] of the Standards Working Group.
  
 
= Positions on the vote =
 
= Positions on the vote =
''Please don't edit this section - it is now locked to ensure editorial review. You may send comments to Cameron Shorter AT gmail .com''
 
  
The discussion raises a number of issues, many based upon complex technical concepts and implications. This makes it difficult for voting OGC members considering whether to support "Geoservices REST API" as a standard. The following provides one analysis of the positions on the vote, aimed to simplify and summarize key points, however, it does not necessarily represent the opinions held by all signatories above.
+
The discussion raises a number of issues, many based upon complex technical concepts and implications. This makes it difficult for voting OGC members considering whether to support (or not) the "Geoservices REST API" as a standard. The following provides one analysis of the positions on the vote, aimed to simplify and summarize key points. However, it does not necessarily represent the opinions held by all signatories above.
  
 
; The pros for accepting the "Geoservices REST API" document as an OGC standard:
 
; The pros for accepting the "Geoservices REST API" document as an OGC standard:
Line 169: Line 230:
 
; The cons:
 
; The cons:
  
:* The OGC is in the position of recommending interoperable standards for geospatial services. The proposed document is not good enough, not widely enough implemented, and not publicly supported enough, to be considered at the same level as existing standards.
+
:* The OGC actually is, whether it should be or not, in the position of recommending interoperable standards for geospatial services. The proposed document is not good enough, has implementations dominated by one vendor's server implementation, and not publicly supported enough, to be considered at the same level as existing standards.
:* Adopting a standard implies a desire to maintain the standard, but OGC's desire to support this approach by has been questioned by some. In particular, the lack of collaboration and willingness to accept recommendations from the community on this version of the "Geoservices REST API" document bodes ill for the future.
+
:* Adopting a standard implies a desire to maintain the standard, but OGC's desire to support this approach has been questioned by some. In particular, the lack of collaboration and willingness to accept recommendations from the community on this version of the "Geoservices REST API" document bodes ill for the future.
 
:* The overlap in functionality between the proposed services and the existing services, notably with the ongoing work to modularize the existing services, is almost 100 percent. However, compatibility is low.
 
:* The overlap in functionality between the proposed services and the existing services, notably with the ongoing work to modularize the existing services, is almost 100 percent. However, compatibility is low.
 
:* There is already a published document: http://www.esri.com/library/whitepapers/pdfs/geoservices-rest-spec.pdf so there is no need for the document to be adopted as an OGC Standard merely for interoperability with the ESRI implementation.
 
:* There is already a published document: http://www.esri.com/library/whitepapers/pdfs/geoservices-rest-spec.pdf so there is no need for the document to be adopted as an OGC Standard merely for interoperability with the ESRI implementation.
 
:* The document, as a new, separate effort, repeats mistakes which were made and since solved by the other services.
 
:* The document, as a new, separate effort, repeats mistakes which were made and since solved by the other services.
 
:* The document focuses on the past (notably with backwards compatibility and use of only GET/POST) not on the future.
 
:* The document focuses on the past (notably with backwards compatibility and use of only GET/POST) not on the future.
:* The document needs a comprehensive editorial rewrite. (see at end)
+
:* The document needs a comprehensive editorial review and substantial rewriting for clarity.
  
 
; A conclusion:
 
; A conclusion:
Line 187: Line 248:
 
Is there any third way?
 
Is there any third way?
  
Well, actually, there is a different way of thinking of the issue. Overall, there appears to be a shared desire for an integrated suite of geospatial services, originally focused on a simple data model, built on the exchange of well defined resources in simple formats including JSON, accessible and usable using the core HTTP verbs, and discoverable through following HTML links and patterns of URL paths. The hope is that such a suite can be designed based on the best expertise of the OGC, can be widely supported by the community, and can be implemented and tested by multiple groups. Neither the proposed document, nor the current services meet this vision. So the work, ultimately, is on improving all the services at the OGC, first to modularize them, then to enable simple implementations, and finally to link those implementations into a functional suite. Since this is the work that is already happening, perhaps the vote is an unfortunate distraction and the productive way forwards merely to redouble the efforts to create the next versions of the standards.
+
Well, actually, there is a different way of thinking of the issue. Overall, there appears to be a shared desire for an integrated suite of geospatial services, originally focused on a simple data model, built on the exchange of well defined resources in simple formats including JSON, accessible and usable using the core HTTP verbs, and discoverable through following HTML links and patterns of URL paths. The hope is that such a suite can be designed based on the best expertise of the OGC, can be widely supported by the community, and can be implemented and tested by multiple groups. Neither the proposed document, nor the current services meet this vision. So the work, ultimately, is on improving all the services at the OGC, first to modularize them, then to enable simple implementations, and finally to link those implementations into a functional suite. Since this is the work that is already happening, perhaps the vote is an unfortunate distraction and the productive way forward is merely to redouble the efforts to create the next versions of the standards.
  
 
= Issues with the document =
 
= Issues with the document =
 
''Please don't edit this section - it is now locked to ensure editorial review. You may send comments to Cameron Shorter AT gmail .com''
 
  
 
Beyond the controversy described above, there are issues with the Geoservices REST API document itself. Even if the standard deserves support, these issues could be considered blockers to the adoption of the current, May 2013, document.
 
Beyond the controversy described above, there are issues with the Geoservices REST API document itself. Even if the standard deserves support, these issues could be considered blockers to the adoption of the current, May 2013, document.
Line 202: Line 261:
  
 
= Further Concerns =
 
= Further Concerns =
--- DRAFT ____
 
 
''Please add concerns not addressed above as bullet points below. Try to be concise, and try not to repeat concepts which have been covered above. Points you have previously added, which are now covered above should be removed. Where appropriate, link to external web pages (such as email achieves)''
 
 
== Political Concerns ==
 
 
* Adopting the standard will expose the OGC to a strong suspicion of acting as a rubber stamp organization under ESRI weight, and will be detrimental to its recognized position as a reference organization for geospatial standards.
 
* It is a dubious practice that a standardization organisation promotes competing standards, without explicitely obsoleting (or at least recommending) some of them. How is a newcomer to the industry supposed to select the appropriate standard if several ones share the same scope : WFS or GeoServices REST API Feature Service, WMS or GeoServices REST API Map Service, etc. ?
 
 
== Commercial Concerns ==
 
 
* Promoting standards from an existing implementation made by a single vendor leads to an obvious bias in competition.
 
* Supporting multiple overlapping standards greatly reduces usability while it increases complexity and cost of development and maintenance.
 
* Many SME's have invested in supporting existing OGC standards in their products. They will be forced to choose the standards they support (and can explain), resulting in decreased interoperability, confusion and frustration for clients.
 
* Confusing customers with new, overlapping OGC standards will lower the credibility of companies and of OGC, reducing business opportunities.
 
  
 
== Technical Concerns ==
 
== Technical Concerns ==
  
* The Geoservices REST API overlaps in large proportion with existing OGC standards such as WMS, WCS, WFS, WMTS, CSW, with no effort made to reconcile with those standards.
+
* see [http://wiki.osgeo.org/wiki/Geoservices_REST_API_critique#The_Technical_Approach this discussion] for detailed arguments why OGC WCS is superior to the "GeoServices REST API" Part 6. It concludes:
* The standardization of WKT for Spatial reference systems is unfortunately currently quite weak in OGC standards. Geoservices REST API is tied with ESRI's version of WKT, which is not properly specified in the Geoservices REST API documents, and is known to be incompatible with other OGC documents, which will lead to a larger confusion. See the following [http://lists.opengeospatial.org/pipermail/requests/2012-July/000166.html comment] for more details on this issue.
+
: ''In summary, the ESRI "Geoservice REST API" Imaging part is at a technological level where WCS departed from some 5 years ago. Inconciseness of the specification at large will make it difficult for third parties to come up with interoperable implementations. The components making up the ESRI "Geoservice REST API" provide natural blocks assignable to the matching SWGs. As for Part 6 of the ESRI "Geoservice REST API", if to become a standard it needs to be discussed in the WCS.SWG for harmonization, clarification, and improvement.''
* The Geoservices REST API is not particularly RESTful - it's a thinly disguised service call, not an address space for RESTful objects that can be operated on.
 
* At least as far as "imagery" is concerned, OGC standards arguably are substantially more mature, powerful, flexible, and modular then the ESRI "Geoservice REST API" Part 6 (and some design principles suggest that scalability may be hampered as well):
 
** data model:
 
*** the ESRI "Geoservice REST API" appears constrained to 2-D imagery, plus optional time stamps. OGC has established a [http://en.wikipedia.org/wiki/Coverage_data unified coverage model] which fully supports n-D spatio-temporal data. It allows use and exchange of coverages between different services, such as [http://en.wikipedia.org/wiki/Web_Coverage_Service WCS], [http://en.wikipedia.org/wiki/Web_Coverage_Processing_Service WCPS], WPS, and SWE.
 
*** OGC coverages support both regular and irregular grids; the ESRI "Geoservice REST API" supports only regular grids, more specifically: only rectified grids with quadrilateral pixels.
 
*** the ESRI "Geoservice REST API"  lacks support for temporal data; it only offers timestamps, measured in milliseconds; this is inconvenient for users and immediately excludes, e.g., geological dates. OGC has established uniform handling of horizontal, vertical, and temporal coordinate reference systems (CRSs), following a deep consensus process with GIS science and backwards compatible with EPSG. The ESRI "Geoservice REST API" specific way of handling coordinates is not known to support this, thereby excluding appropriate timeseries handling in remote sensing, air traffic, MetOcean, etc.
 
*** OGC coverages provide a concise, versatile model for supporting different binary formats; the ESRI "Geoservice REST API" supports only very few selected 2-D formats, excluding, e.g., JPEG2000, NetCDF, HDF, etc.
 
*** the ESRI "Geoservice REST API" lacks a clear model of their data structures, it can be deduced only implicitly from the operation mechanics.
 
** service model:
 
*** The ESRI "Geoservice REST API" Part 6 lacks conciseness, thereby opening up ways for implementations that are not interoperable. For developers of alternative implementations this may mean they have to acquire ESRI licenses for finding out the intended behavior.
 
*** Functionality in the ESRI "Geoservice REST API" appears randomly chosen, with no clear concept visible; this burdens implementers while still leaving holes of functionality. For example, this functionality appears restricted to mapping applications and does not easily extend into other domains.
 
*** It has been said that the ESRI "Geoservice REST API" can be seen as a "wrapper around OGC W*S" services. This is not true for WCS (and WCPS), at least: the ESRI "Geoservice REST API" Part 6 is too poor in functionality and too different in mechanics to accomplish this.
 
** In summary, the ESRI "Geoservice REST API" Imaging part is at a technological level where WCS departed from some 5 years ago. Inconciseness of the specification at large will make it difficult for third parties to come up with interoperable implementations. The components making up the ESRI "Geoservice REST API" provide natural blocks assignable to the matching SWGs. As for Part 6 of the ESRI "Geoservice REST API", if to become a standard it needs to be discussed in the WCS.SWG for harmonization, clarification, and improvement.
 
  
 
== Methodological Concerns ==
 
== Methodological Concerns ==
  
# No public response (nor private to the authors of the comments) has been made to the various comments sent on the OGC Requests mailing list in [[http://lists.opengeospatial.org/pipermail/requests/2012-July/date.html July 2012]] and [[http://lists.opengeospatial.org/pipermail/requests/2012-August/date.html August 2012]] during the 30 day public comments period.
+
* The Geoservices REST API can not be amended (other than editorial changes in the specification document), because of a requirement for backward compatibility with the ESRI implementation. This has limited improvements in this version of the candidate specification.
# The Geoservices REST API can not be amended (other than editorial changes in the specification document), because of a requirement of backward compatibility with ESRI implementation. Consequently, the standard is unlikely to improve, or its evolution will be only lead by ESRI.
 
# OGC standards normally require interoperability experiments and a richer process to ratify a standard such as this one. No explanation has been forthcoming as to why a simplified process is appropriate in this case.
 
# ESRI/OGC have specifically [http://lists.osgeo.org/pipermail/discuss/2013-May/011659.html rejected requests] to openly share their justifications document being selectively sent to OGC voters.
 
 
 
A response (from Adrian Custer):
 
 
 
# The OGC is working to release those documents to the public as of 9 May 2013.
 
# Work on the next version of the document can take any perspective acceptable to those working on the document. (The OGC has no method in place in case two groups want to evolve the document in two different directions.)
 
# That is not true, the OGC does not require interoperability experiments or other processes.
 
  
 
= Further Reading =
 
= Further Reading =
''Please add links to referenced documents, related news stories or blog posts here.''
+
* Cameron Shorter's [http://cameronshorter.blogspot.com.au/2013/05/will-ogcs-standards-meet-government.html Will OGC’s standards meet government purchasing guidelines?]
* Call for comments on GeoServices REST API: http://www.opengeospatial.org/standards/requests/89
 
 
* Email archive of OSGeo discussions about GeoServices REST API: http://lists.osgeo.org/pipermail/discuss/2013-May/thread.html
 
* Email archive of OSGeo discussions about GeoServices REST API: http://lists.osgeo.org/pipermail/discuss/2013-May/thread.html
 
* Adrian Custer's summary of technical issues (and original source of some content in this letter): http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html
 
* Adrian Custer's summary of technical issues (and original source of some content in this letter): http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html
 
* "Is OGC Loosing its way?", letter to OGC Voters, from OGC Interoperability Movement Team Leaders, http://lists.osgeo.org/pipermail/discuss/2013-May/011632.html
 
* "Is OGC Loosing its way?", letter to OGC Voters, from OGC Interoperability Movement Team Leaders, http://lists.osgeo.org/pipermail/discuss/2013-May/011632.html
 +
 +
* Call for comments on GeoServices REST API: http://www.opengeospatial.org/standards/requests/89
 +
* Responses from the Standards Working Group to the comments received from the public during the public Request for Comments (RFC): [[file:OGC_12-642_GeoServices_REST_API_-_RFC_Comments_Response.pdf|OGC 12-646 Response to RFC Comments]]
 +
* Responses from the Standards Working Group to the reasons given by the organizations voting _no_ during the adoption vote: [[file:OGC_13-031r1_GeoServices_REST_API_-_Response_to_no_votes_r1.pdf|OGC 13-031r1 Response to 'no' votes]]
 +
 +
= Outcomes =
 +
After delivery of this open letter, there were similar considered concerns raised by some members within the OGC community. As a result, the GeoServices REST API was [http://cameronshorter.blogspot.com.au/2013/05/ogc-heed-community-pressure-regarding.html withdrawn] as a proposed OGC standard. The OGC then initiated an [http://cameronshorter.blogspot.com.au/2013/11/ideas4ogc-phoenix-rising-from.html Ideas4OGC review], to rebaseline OGC priorities and processes in order to address weaknesses that had been identified in OGC processes.
 +
 +
News writeup of the story here: http://www.itnews.com.au/News/345493,open-source-crusade-blocks-geospatial-standard.aspx/0
  
 
[[Category: OGC]]
 
[[Category: OGC]]
 
[[Category: Standards]]
 
[[Category: Standards]]

Latest revision as of 14:00, 30 July 2015

This page aims to collate community concerns related to the adoption of the "Geoservices REST API" document as a standard of the Open Geospatial Consortium (OGC). The page has been collaboratively edited, and delivered by the board of the OSGeo Foundation (OSGeo) to the OGC and OGC voting members on Friday 17 May 2013.

The version of the document delivered can be found here: http://wiki.osgeo.org/index.php?title=Geoservices_REST_API&oldid=71311

Cover Letter from the OSGeo Board

The board of the Open Source Geospatial Foundation (OSGeo) is presenting this letter to the OGC. The letter highlights concerns about the "GeoServices REST API" from many people within the OSGeo community. As always, if there is anything the OSGeo board can do to help, then please let us know.

Signed: Jeff McKenna (OSGeo president), Peter Batty, Jáchym Čepický, Michael Gerlek, Anne Ghisla, Mark Lucas, Daniel Morissette, Cameron Shorter, Frank Warmerdam

Open Letter to OGC and voting members

May 2013

We, the undersigned, have concerns that approving the "Geoservices REST API" as an OGC standard, will have detrimental impacts on interoperability within the spatial industry.

We strongly urge that the proposed "Geoservices REST API", as it stands in May 2013, be rejected as an OGC standard.

People have listed different reasons for concern. These concerns are described below.

Signed

  1. Cameron Shorter, Geospatial Solutions Director at LISAsoft, core contributor & coordinator of OSGeo-Live, OSGeo Board member
  2. Mark Lucas, Founding member and board of directors for OSGeo foundation, Principal Scientist for RadiantBlue Technologies Inc.
  3. Stephen Woodbridge, Director of iMaptools.com, Contributor and/or PSC of Mapserver, pgRouting, PAGC, and PostGIS
  4. Even Rouault, Geospatial developer, OSGeo Charter Member, core contributor and PSC member of GDAL/OGR, contributor of Mapserver, PROJ.4, libgeotiff, shapelib, libtiff
  5. Gerhard Triebnig, Managing Director at EOX IT Services GmbH
  6. Brent Wood, Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
  7. Stephan Meissl, CTO at EOX IT Services GmbH, contributor to Mapserver, PSC chair of EOxServer
  8. Jeroen Ticheler, Director of GeoCat, project founder and PSC chair of GeoNetwork opensource
  9. Just van den Broecke, Director at Just Objects, contributor to Heron Mapping Client, secretary of OSGeo Dutch Local Chapter, member at OpenGeoGroep
  10. Milo van der Linden, member at OpenGeoGroep
  11. Landon Blake, GIS Department Manager/Land Surveyor at KSN, OSGeo California Chapter Board Representative.
  12. Daniel Morissette, President at Mapgears, OSGeo Board member, core contributor and PSC member of Mapserver and GDAL/OGR. Former OGC TC member and involved in the implementation of several OGC WxS specs in MapServer.
  13. Bob Basques, GIS Systems Developer at the City of Saint Paul, MN. Public Works GIS (GISmo), Technical Director at SharedGeo, OSGeo Charter Member, OSGeo TCMUG local chapter member, Co-founder and PSC member of GeoMoose project.
  14. Pedro-Juan Ferrer Matoses, PM at Omnium Strategic Intelligence, Spain, OSGeo Charter Member, OSGeo Spanish Local Chapter Liaison officer.
  15. Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
  16. María Arias de Reyna, software engineer at GeoCat, Spain, member of OSGeo Spanish Local Chapter.
  17. Anne Ghisla, OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
  18. Micho Garcia, Freelance and member of geomati.co, Spain, member of Spanish Local Chapter
  19. Margherita Di Leo, OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
  20. Jorge Sanz, GIS Consultant at Prodevelop, OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
  21. Pablo Sanxiao, CTO and co-founder at iCarto, OSGeo Spanish Local Chapter Member, Spain
  22. Frank Steggink, GIS software developer at Vicrea, The Netherlands, member of the Dutch Local Chapter
  23. Olivier Courtin, Oslandia co-founder, core contributor or/and PSC member of Mapserver and PostGIS. OGC TC member.
  24. Wladimir Szczerban, OSGeo Spanish Local Chapter Member, Spain
  25. Anita Graser, GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
  26. Volker Mische, geospatial software engineer, creator of GeoCouch
  27. Iván Sánchez, OSGeo Spanish Local Chapter Member, head of OpenStreetMap Spain, OpenStreetMap Foundation member, Humanitarian OpenStreetMap Team member, Spanish SDI working group member
  28. Gabriel Carrión, Strategy Manager at gvSIG association
  29. Sandro Santilli, OSGeo Charter Member, PostGIS and GEOS PSC member and core hacker.
  30. Javier Diaz, member of Geoinquietos Bs As [1], member of the Organizing Committee FOSS4G Bs As 2013 [2]
  31. Jo Cook, Consultant at Astun Technology, former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of FOSS4G 2013
  32. Francisco José Peñarrubia, CTO and co-founder at SCOLAB. Members of gvSIG Association
  33. Shanmugam Ganeshkumar, Director of GeoICON, member OSGeo Malaysia Chapter
  34. Barry Rowlingson, Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
  35. Stefan Keller, University of Applied Sciences, Rapperswil (Switzerland), Member of Swiss OSM (SOSM) and QGIS association and of organizing committees of pgConf.DE and FOSSGIS 2013, and member of eCH (e-government standards of Switzerland)
  36. Andrew Bailey, OSGeo member, Astun Technology
  37. Suchith Anand, OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
  38. Carlos Krefft, GIS software developer at CSTARS - University of Miami, OGC and OSGeo Member.
  39. Stefano Costa, OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
  40. Peter Baumann, Jacobs University, OGC member, WCS.SWG chair, editor of 10+ specs (disclaimer: this is an expression of my personal opinion and not in any way endorsed by OGC)
  41. Peter Batty, CTO of Geospatial Division at Ubisense, OSGeo board member, former CTO of Intergraph and GE Smallworld, Technical Committee member of OGC in its formative years c 1995-97
  42. Barend Köbben, OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at ITC-University of Twente
  43. Paolo Cavallini, Faunalia, OSGeo member, GFOSS.it member and former president, QGIS-PSC
  44. FRans Thamura, Indonesia, OSGeo Indonesia, organizer]
  45. Sanghee Shin, Founder and CEO of Gaia3D, OSGeo Charter Member, Representative of OSGeo Korean Chapter, Chairman of Open Source GIS Alliance Korea
  46. Benni Purwonegoro,Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
  47. Jachym Cepicky, Czech Republic, member of OSGeo Board of Directors
  48. Pat Cappelaere, Vightel Corporation
  49. Jürgen Fischer, norBIT GmbH, QGIS core developer
  50. Maria Antonia Brovelli, OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at Politecnico di Milano, Italy
  51. Nacho Varela, GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
  52. Vasile Craciunescu, OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
  53. Abbas Abdul Wahab, Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
  54. Roy Braam, Software Engineer @ | B3Partners
  55. Peteris Bruns, Latvia, GIS Consultant & Software Engineer @ | SunGIS
  56. Giovanni Manghi, Portugal, NaturalGIS, OSGeo member, OSGeo-Portugal
  57. Hugo Martins, UK, Lutra Consulting, WebGIS Developer, OSGeo-Portugal Member
  58. Saber Razmjooei, UK, Lutra Consulting, Co-Founder
  59. Peter Wells, UK, Lutra Consulting, Co-Founder
  60. Sidney Gijzen, The Netherlands, Researcher GIS @ Alterra, Wageningen UR
  61. Miles Fidelman, US, Principal, Protocol Technologies Group, LLC
  62. Puneet Kishor, OSGeo Charter Member; Geology, Univ. of Wisconsin-Madison; Creative Commons
  63. António José Silva, Portugal, GIS Consultant, OSGeo-Portugal Member
  64. AndreMano, Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
  65. Mauricio Miranda, Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
  66. Paulo Machado, Portugal, Software Engineer @ PT Inovação
  67. Alvaro Anguix, Spain, General Manager at gvSIG Association
  68. Santiago Higuera, CEO at Mercatorlab, OSGeo Spanish Local Chapter Board Member, Spain
  69. Alan Boudreault, Developer at Mapgears, contributor to Mapserver and GDAL/OGR.
  70. Mike Saunt, UK, Owner at Astun Technology Ltd, OSGeo sponsor
  71. Michael Smith, OSGeo Charter Member, Physical Scientist US Army Corps of Engineers Remote Sensing GIS Center
  72. Angelos Tzotsos, OSGeo Charter Member, Researcher at National Technical University of Athens
  73. Michaël Douchin, France, GIS consultant & software engineer at 3liz
  74. Pedro Venâncio, Portugal, GIS Analyst @ Municipality of Pinhel
  75. Jorge Gustavo Rocha, Portugal, GIS Professor at Universidade do Minho
  76. Daniel Kastl, Japan, Georepublic, Founder
  77. John Callahan, US, Research Scientist and GIS/Remote Sensing Specialist, University of Delaware
  78. Kalyan Janakiraman, Senior Systems Analyst, Business Development Services, NSW Land and Property Information, Sydney, Australia
  79. Phillip Davis, Director, National Geospatial Technology Center of Excellence, Texas, USA
  80. Simon Pigot, contributor to and PSC member of GeoNetwork opensource (speaking for myself, not an official view of my employer)
  81. John Bryant, Consultant, Mammoth Mapping, Dawson City, Canada and GIS/DB Admin, Jupiter Mines, Perth, Australia
  82. Christos Iossifides, Remote Sensing Instructor, Laboratory Teaching Staff, Remote Sensing Instructor and Researcher, National Technical University of Athens
  83. Tim Bowden, Spatial Consultant, Perth, Australia
  84. Luca Delucchi, GIS Technician, Trento, Italy
  85. Bart van den Eijnden, GIS software developer, Utrecht, Netherlands
  86. Henry Addo, Software Developer at Ushahidi [3], contributor of OSGeo-Live
  87. Stefano Iacovella, GIS consultant & software engineer, Rome, Italy
  88. Meine Toonen, Software Engineer @ B3Partners, The Netherlands
  89. Arne Kepp, Software Engineer, Oslo, Norway
  90. Pirmin Kalberer, Managing director Sourcepole, FOSSGIS member, Contributor of GDAL/OGR, QGIS, Mapfish, UbuntuGIS, OSGeo-Live, Switzerland
  91. Dr. Horst Düster, Managing director Sourcepole, FOSSGIS member, QGIS Project Treasurer and Contributor of QGIS, Zürich, Switzerland
  92. Richard Duivenvoorde, Managing director & software developer Webmapper, QGIS community member
  93. Steven Feldman, Principal at KnowWhere Consulting and Chair of the LOC for FOSS4G 2013
  94. Edward Mac Gillavry, Managing director & software developer Webmapper
  95. Maxim Dubinin, CEO at NextGIS, head of GIS-Lab.info
  96. Fran Boon, PMC Chair at Sahana Foundation, CTO of AidIQ
  97. Ian Edwards, Chair OSGeo:UK
  98. Dmitriy Baryshnikov Developer at NextGIS, GDAL/OGR committer, wxGIS developer, GIS-Lab.info community member
  99. Chris van Lith, Director B3Partners, member of OpenGeoGroep
  100. Vincent Picavet, co-founder of Oslandia, founding member and treasurer of OSGeo-FR
  101. Stefan A. Tzeggai, creator of AtlasStyler SLD editor, founder of empirica systeme gmbh
  102. Roald de Wit, Geospatial Software Engineer, Melbourne, Australia
  103. Manuel Grizonnet, working at the French Space Agency, ORFEO ToolBox library developer
  104. Toru Mori, President & CEO, Orkney, Inc., Yokohama, Japan, Representative of OSGeo Japan Chapter, OSGeo Charter Member
  105. Markus Schneider, TMC chair of the deegree project, CEO of Occam Labs
  106. Elena Mezzini, Remote Sensing and GIS Technician, GFOSS.it member, Bologna, Italy
  107. Alexander Bruy, NextGIS, QGIS core developer
  108. Danilo Furtado, Portugal, OSGeo member, OSGeo-Portugal
  109. Andreas Schmitz, Germany, deegree core developer and TMC member, CTO of Occam Labs
  110. Oliver Tonnhofer, Germany, MapProxy core developer, founder & CTO of Omniscale
  111. Thomas Baschetti, Germany, Freelancer, Mapbender PSC Member, FOSSGIS member
  112. Ian Mayo, GeoSpatial developer, UK
  113. Ivan Mincik, CEO of GISTA s.r.o., Slovakia
  114. Edmar Moretti, Software developer, i3GEO core developer, Brazil
  115. Diego Moreira, GIS Analyst, Contributor of QGIS, Brazil
  116. Luigi Pirelli, Freelance Analyst/Programmer, co-founder of Italian OSGEO Local Chapter GFOSS.it, Italy
  117. Kyle Shannon Software Developer, contributor of GDAL/OGR, United States
  118. David Mateos, worker-owner at Terrativa S. Coop. and OSGeo Spanish Local Chapter Member, Spain
  119. Luis Franco, researcher and GIS analyst at the University of Santiago de Compostela, Spain
  120. Gabriel Roldan, Software Developer, Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Member
  121. Dimitris Kotzinos, OSGEO Charter Member, OSGEO Greek Chapter founder, Assistant Professor TEI of Serres, Greece
  122. Stefan Steiniger, owner of GEO Steiniger Ltda., contributor to OpenJUMP GIS and OpenTripPlanner and author of several FOSS4G overview articles, Canada/Chile
  123. Nobusuke Iwasaki, Senior Researcher, National Institute for Agro-Environmental Sciences, Tsukuba, Japan, OSGeo Japan Chapter Board Member
  124. Ross Johnson, Land Information Officer, City of Ryde Council and NSW Committee member of Surveying & Spatial Sciences Institute (SSSI)
  125. Kumaran Narayanaswamy, CEO & Managing Director of kCube Consultancy Services Pvt Ltd India.[4], Member of India OSGeo Chapter.
  126. Luis Fernando Bueno, Professor at Federal University of Rondonia, researcher and GIS analyst, Brazil.
  127. Bob Bruce, FEC, P.Eng., Geomatics Engineer, Winnipeg, Manitoba, Canada.
  128. Moritz Lennert, Researcher in geography at the Free University of Brussels (ULB), GRASS-PSC
  129. Ian Turton, Software developer and open standards advocate, GeoTools-PSC
  130. Gérald Fenoy, OSGeo Charter member, Founder and CEO of GeoLabs SARL, France
  131. David Bitner, OSGeo Charter member, OSGeo VP for Geodata, OSGeo Twin Cities Chapter, Sahana Software Foundation Board of Directors, MetroGIS Coordinating Committee Chair, owner dbSpatial
  132. Peter Löwe, OSGeo Charter member, Senior Researcher at Deutsches GeoForschungsZentrum GFZ, General Manager GISIX.com
  133. Gavin Fleming, OSGeo Charter member, owner of AfriSpatial.
  134. Frank Maes, GeoICT professional, Head Operations at Geosparc, Contributor & community member of Geomajas, OSGeo member
  135. Massimo Di Stefano , OSGeo Charter Member, Italy, founder-member of OSGeo Italian Local Chapter.
  136. Paolo Corti, Geospatial software developer, Rome, Italy
  137. Marco Lechner, chairman FOSSGIS e.V. (OSGeo local chapter D-A-CH)

Summary

The OGC candidate standard titled "GeoServices REST API" is currently, in May 2013, being considered to be approved as an Open Geospatial Consortium (OGC) standard. The vote to accept the document as a standard is unusually contentious. The controversy is the cause of this open letter.

The candidate standard was previously released for public comment and can be found on the request for public comment page (though public comment has been closed for now).

The candidate standard attempts to standardize a suite of web services such as a service which provides map images, a service which provides geospatial feature data, and a service which performs geospatial processing. The candidate standard focuses on interactions via a defined hierarchy of URLs and using predominantly a particular set of JSON schemas for the exchange of geospatial data.

Criticism and Response

The criticism of the adoption of this particular document as an OGC Standard includes a wide variety of reasons such as:

  • the OGC's process through which the document was developed which is thought to lack sufficient flexibility to respond to input from various stakeholders,
  • the focus of the document on 'REST' and 'API' which is seen as not matching the ideas others have for these concepts,
  • the names of the standard and of the services which are seen as potentially confusing,
  • the functionality of the new services which are considered to duplicate that of existing services already standardized by the OGC such as WMS, WFS, WCS, and WPS,
  • the addition of a new set of services based on new URL patterns and new JSON exchange formats which is seen as duplicating the efforts of other working groups bringing similar ideas to the updates of existing OGC services,
  • the re-introduction in the new services of previously resolved interoperability issues which is seen as failing to build on the existing knowledge and experience,
  • the use of the particular JSON schemas which are seen as having little industry acceptance and are incompatible with other widely used schemas, and
  • the lack of implementation diversity which is thought to give the vendor of the one complete implementation an unusual commercial advantage on top of the vendor's already dominant position in the domain.

These issues have potential impacts on the use of 'Open Standards' by governments and companies, on the interoperability of software interacting with standards compliant OGC services, on the costs to developers and users of standards compliant software, on the understanding of 'Open Standards' by the public at large, and, possibly, on the reputation of the OGC as a champion of interoperability.

In particular there are concerns by some that adoption of the standard will likely result in a combination of the following:

  1. The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
  2. Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
  3. Sponsors (such as governments) who require compliance with OGC standards will discover that applications don't communicate together, due to applications supporting different OGC standards that essentially do the same thing.
  4. This will result in a diminished importance of OGC, as the "OGC standards" stamp of approval will not equate interoperability.
  5. After a while, in order to solve interoperability issues, a respected international organisation or program will likely take the initiative to mandate one standard as the preferred standard for all agencies to follow. To date, the OGC has provided this leadership.
  6. One standard taking prominence over the other will likely lead to the other being neglected or deprecated, resulting in many OGC compliant systems becoming legacy systems in the process. This should be considered an undesirable outcome for a standards organisation.

In response to these issues, the authors of the Geoservices REST API document have stated that:

  • the process of the OGC has been followed completely,
  • the specification actually is RESTful and does define an API,
  • the name, due to the controversy, is open for modification
  • the OGC does not forbid duplication of service functionality, already has duplication between the W*S and the S*S (sensor) family of standards, should not block progress in the name of 'one true way', and harmonization between the services can be considered in the future,
  • the JSON format exists and functions, and
  • there are alternative implementations for some of these services.

The authors also stress that the existence of a large user base shows the service is useful, and that the standardization of the services at the OGC may encourage new implementations.

The SWG has published two documents in response to various comments.

  • OGC 12-646 Response to RFC Comments presents the responses from the Standards Working Group to the comments received from the public during the public Request for Comments (RFC).
  • OGC 13-031r1 Response to 'no' votes presents the responses from the Standards Working Group to the reasons given by the organizations voting _no_ during the adoption vote.

Both are available through the links above, or via the public page of the Standards Working Group.

Positions on the vote

The discussion raises a number of issues, many based upon complex technical concepts and implications. This makes it difficult for voting OGC members considering whether to support (or not) the "Geoservices REST API" as a standard. The following provides one analysis of the positions on the vote, aimed to simplify and summarize key points. However, it does not necessarily represent the opinions held by all signatories above.

The pros for accepting the "Geoservices REST API" document as an OGC standard
  • The OGC should be in the business of developing good standards, not in choosing which standards should be implemented.
  • The proposers of the document want to make a standard and have followed all the rules of the OGC. The work of any such group of members deserves serious, good faith consideration.
  • The need for an integrated suite of services using simple data, which is addressed (partially) by the document, is real. The proposed document is pushing the OGC on this issue.
  • The proposed document could be useful to a number of people.
  • The proposed document is not significantly more broken than the existing standards of the OGC. As one author of standards notes:
"I know how totally impossible it is to write a good standard, so the weaknesses in the existing document seem more acceptable."
The cons
  • The OGC actually is, whether it should be or not, in the position of recommending interoperable standards for geospatial services. The proposed document is not good enough, has implementations dominated by one vendor's server implementation, and not publicly supported enough, to be considered at the same level as existing standards.
  • Adopting a standard implies a desire to maintain the standard, but OGC's desire to support this approach has been questioned by some. In particular, the lack of collaboration and willingness to accept recommendations from the community on this version of the "Geoservices REST API" document bodes ill for the future.
  • The overlap in functionality between the proposed services and the existing services, notably with the ongoing work to modularize the existing services, is almost 100 percent. However, compatibility is low.
  • There is already a published document: http://www.esri.com/library/whitepapers/pdfs/geoservices-rest-spec.pdf so there is no need for the document to be adopted as an OGC Standard merely for interoperability with the ESRI implementation.
  • The document, as a new, separate effort, repeats mistakes which were made and since solved by the other services.
  • The document focuses on the past (notably with backwards compatibility and use of only GET/POST) not on the future.
  • The document needs a comprehensive editorial review and substantial rewriting for clarity.
A conclusion

Both simple answers are bad.

A simple acceptance of the standard would introduce a new set of 'OGC approved' open services. The OGC approval might enable governments to buy a XXXX-new-name-here-XXXX solution instead of a W*S or a S*S solution. The path forwards towards harmonizing the services is unclear. Fixing this document in addition to fixing the W*S services will be a pain.

Simply rejecting the solution would be bad for the OGC. It would place the OGC in the position of picking winners and losers in the standards business. It would mean that the OGC is stuck on the project of fixing the W*S standards to meet some nebulous future functionality without having any path to get there. It would discourage innovation and progress.

Is there any third way?

Well, actually, there is a different way of thinking of the issue. Overall, there appears to be a shared desire for an integrated suite of geospatial services, originally focused on a simple data model, built on the exchange of well defined resources in simple formats including JSON, accessible and usable using the core HTTP verbs, and discoverable through following HTML links and patterns of URL paths. The hope is that such a suite can be designed based on the best expertise of the OGC, can be widely supported by the community, and can be implemented and tested by multiple groups. Neither the proposed document, nor the current services meet this vision. So the work, ultimately, is on improving all the services at the OGC, first to modularize them, then to enable simple implementations, and finally to link those implementations into a functional suite. Since this is the work that is already happening, perhaps the vote is an unfortunate distraction and the productive way forward is merely to redouble the efforts to create the next versions of the standards.

Issues with the document

Beyond the controversy described above, there are issues with the Geoservices REST API document itself. Even if the standard deserves support, these issues could be considered blockers to the adoption of the current, May 2013, document.

The critique is incomplete because it quickly falls into a full editorial review of the text, something which takes a lot of time and effort and is beyond the scope and intent of this Open Letter.

The critique can be found at: http://wiki.osgeo.org/wiki/Geoservices_REST_API_critique.

Note that some of these critiques hold the document to OGC's current, standards writing guidelines. The OGC has been striving to develop better standards so new standards must meet higher requirements than past standards. The lack of clarity in the proposed document is not substantially worse than many published standards but ought to be resolved in new standards.

Further Concerns

Technical Concerns

  • see this discussion for detailed arguments why OGC WCS is superior to the "GeoServices REST API" Part 6. It concludes:
In summary, the ESRI "Geoservice REST API" Imaging part is at a technological level where WCS departed from some 5 years ago. Inconciseness of the specification at large will make it difficult for third parties to come up with interoperable implementations. The components making up the ESRI "Geoservice REST API" provide natural blocks assignable to the matching SWGs. As for Part 6 of the ESRI "Geoservice REST API", if to become a standard it needs to be discussed in the WCS.SWG for harmonization, clarification, and improvement.

Methodological Concerns

  • The Geoservices REST API can not be amended (other than editorial changes in the specification document), because of a requirement for backward compatibility with the ESRI implementation. This has limited improvements in this version of the candidate specification.

Further Reading

Outcomes

After delivery of this open letter, there were similar considered concerns raised by some members within the OGC community. As a result, the GeoServices REST API was withdrawn as a proposed OGC standard. The OGC then initiated an Ideas4OGC review, to rebaseline OGC priorities and processes in order to address weaknesses that had been identified in OGC processes.

News writeup of the story here: http://www.itnews.com.au/News/345493,open-source-crusade-blocks-geospatial-standard.aspx/0