OSGeo - User contributions [en]

Category talk:Elections

2013-07-09T17:26:56Z

Wiki-Acuster:

''Please add questions to the elections process here and also add suggestions how we can improve the process. This page is open for anybody. ''

=== Member Registry ===
Does OSGeo have a register of current members
* Yes: http://www.osgeo.org/content/foundation/members/voting_members.html

Does the Foundation know who voted and who became inactive
* Yes. This information is maintained by the OSGeo secretary.
** Why is this not public?
** Is lack of participation at least communicated to the members?

=== Bylaws ===
Does anybody understand our [http://www.osgeo.org/content/foundation/incorporation/bylaws.html bylaws]?
* Maybe?
* Do we need to keep them as they are?
* Is there immediate need to change them?

Section 7.7 Automatic Termination.
* Currently Charter Members who have failed to take part in three consecutive elections are moved to dormant. There is no other regular interaction with or between the Charter Members, therefore there are also no meeting minutes or similar to record attendance.
** Actually the stated criterion is 'participated in meetings' which is very different from voting.

=== Role of the CRO ===
The [[Chief_Returning_Officer|Chief Returning Officer]] administers elections.
* Is the CRO allowed to nominate members? Thsi is unclear. There has been one complaint in 2012 but no further action was taken. To avoid further discussion the CRO in 2013 (Arnulf Christl) decided to refrain from nominating individuals.
* Is the CRO allowed to take part in the elections (given she is a Charter Member at the time of the elections)?
** Yes (otherwise it may be hard to find anybody taking on the job)

''Please add your questions, ideas, answers.''

Category talk:Elections

2013-07-09T15:44:10Z

Wiki-Acuster: /* Bylaws */

''Please add questions to the elections process here and also add suggestions how we can improve the process. This page is open for anybody. ''

=== Member Registry ===
Does OSGeo have a register of current members
* Yes: http://www.osgeo.org/content/foundation/members/voting_members.html

Does the Foundation know who voted and who became inactive
* Yes. This information is maintained by the OSGeo secretary.
** Why is this not public?
** Is lack of participation at least communicated to the members?

=== Bylaws ===
Does anybody understand our [http://www.osgeo.org/content/foundation/incorporation/bylaws.html bylaws]?
* Maybe?
* Do we need to keep them as they are?
* Is there immediate need to change them?

Section 7.7 Automatic Termination.
* Currently Charter Members who have failed to take part in three consecutive elections are moved to dormant. There is no other regular interaction with or between the Charter Members, therefore there are also no meeting minutes or similar to record attendance.
** Actually the stated criterion is 'participated in meetings' which is very different from voting.

=== Role of the CRO ===
* Is the CRO allowed to nominate members? Thsi is unclear. There has been one complaint in 2012 but no further action was taken. To avoid further discussion the CRO in 2013 (Arnulf Christl) decided to refrain from nominating individuals.
* Is the CRO allowed to take part in the elections (given she is a Charter Member at the time of the elections)?
** Yes (otherwise it may be hard to find anybody taking on the job)

''Please add your questions, ideas, answers.''

Category talk:Elections

2013-07-09T15:43:11Z

Wiki-Acuster: /* Member Registry */

''Please add questions to the elections process here and also add suggestions how we can improve the process. This page is open for anybody. ''

=== Member Registry ===
Does OSGeo have a register of current members
* Yes: http://www.osgeo.org/content/foundation/members/voting_members.html

Does the Foundation know who voted and who became inactive
* Yes. This information is maintained by the OSGeo secretary.
** Why is this not public?
** Is lack of participation at least communicated to the members?

=== Bylaws ===
Does anybody understand our [http://www.osgeo.org/content/foundation/incorporation/bylaws.html bylaws]?
* Maybe?
* Do we need to keep them as they are?
* Is there immediate need to change them?

Section 7.7 Automatic Termination.
* Currently Charter Members who have failed to take part in three consecutive elections are moved to dormant. There is no other regular interaction with or between the Charter Members, therefore there are also no meeting minutes or similar to record attendance.

=== Role of the CRO ===
* Is the CRO allowed to nominate members? Thsi is unclear. There has been one complaint in 2012 but no further action was taken. To avoid further discussion the CRO in 2013 (Arnulf Christl) decided to refrain from nominating individuals.
* Is the CRO allowed to take part in the elections (given she is a Charter Member at the time of the elections)?
** Yes (otherwise it may be hard to find anybody taking on the job)

''Please add your questions, ideas, answers.''

Category talk:Elections

2013-07-09T15:42:41Z

Wiki-Acuster: /* Member Registry */

''Please add questions to the elections process here and also add suggestions how we can improve the process. This page is open for anybody. ''

=== Member Registry ===
Does OSGeo have a register of current members
* Yes: http://www.osgeo.org/content/foundation/members/voting_members.html

Does the Foundation know who voted and who became inactive
* Yes. This information is maintained by the OSGeo secretary.
* Why is this not public?
* Is lack of participation at least communicated to the members?

=== Bylaws ===
Does anybody understand our [http://www.osgeo.org/content/foundation/incorporation/bylaws.html bylaws]?
* Maybe?
* Do we need to keep them as they are?
* Is there immediate need to change them?

Section 7.7 Automatic Termination.
* Currently Charter Members who have failed to take part in three consecutive elections are moved to dormant. There is no other regular interaction with or between the Charter Members, therefore there are also no meeting minutes or similar to record attendance.

=== Role of the CRO ===
* Is the CRO allowed to nominate members? Thsi is unclear. There has been one complaint in 2012 but no further action was taken. To avoid further discussion the CRO in 2013 (Arnulf Christl) decided to refrain from nominating individuals.
* Is the CRO allowed to take part in the elections (given she is a Charter Member at the time of the elections)?
** Yes (otherwise it may be hard to find anybody taking on the job)

''Please add your questions, ideas, answers.''

Geoservices REST API

2013-05-17T11:42:16Z

Wiki-Acuster: /* Criticism and Response */ Fixing markup

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 =

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),
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 ==

# [[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, 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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:vehrka|Pedro-Juan Ferrer Matoses]], PM at Omnium Strategic Intelligence, Spain, OSGeo Charter Member, OSGeo Spanish Local Chapter Liaison officer.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[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:Wellsp | Peter Wells]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
# [[User:maurimiranda|Mauricio Miranda]], Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
# [[User:pmachado|Paulo Machado]], Portugal, Software Engineer @ PT Inovação
# [[User:alvaro|Alvaro Anguix]], Spain, General Manager at [http://www.gvsig.com gvSIG Association]
# [[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].
# [[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, Treasurer QGIS Project [http://qgis.org QGIS], Zürich, Switzerland
# [[User:rduivenvoorde| 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]
# [[User: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 member 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

= 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 [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 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:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.
* [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 =

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 [http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html 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 [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:
: ''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 =
''Please add links to referenced documents, related news stories or blog posts here.''
* 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]]

* 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
* "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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-17T11:25:28Z

Wiki-Acuster: /* Criticism and Response */ Change links to reponse documents to point to the OGC; add the public page of the SWG

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 =

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),
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 ==

# [[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, 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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:vehrka|Pedro-Juan Ferrer Matoses]], PM at Omnium Strategic Intelligence, Spain, OSGeo Charter Member, OSGeo Spanish Local Chapter Liaison officer.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[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:Wellsp | Peter Wells]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
# [[User:maurimiranda|Mauricio Miranda]], Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
# [[User:pmachado|Paulo Machado]], Portugal, Software Engineer @ PT Inovação
# [[User:alvaro|Alvaro Anguix]], Spain, General Manager at [http://www.gvsig.com gvSIG Association]
# [[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].
# [[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, Treasurer QGIS Project [http://qgis.org QGIS], Zürich, Switzerland
# [[User:rduivenvoorde| 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]
# [[User: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 member 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

= 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 [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 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:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.
* [[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 =

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 [http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html 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 [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:
: ''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 =
''Please add links to referenced documents, related news stories or blog posts here.''
* 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]]

* 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
* "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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-15T19:48:11Z

Wiki-Acuster: /* Methodological Concerns */

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.

= 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.

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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go in the "Further Concerns" section below.''

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 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.

== 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
# [[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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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:vehrka|Pedro-Juan Ferrer Matoses]], PM at Omnium Strategic Intelligence, Spain, OSGeo Charter Member, OSGeo Spanish Local Chapter Liaison officer.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[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:Wellsp | Peter Wells]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
# [[User:maurimiranda|Mauricio Miranda]], Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
# [[User:pmachado|Paulo Machado]], Portugal, Software Engineer @ PT Inovação
# [[User:alvaro|Alvaro Anguix]], Spain, General Manager at [http://www.gvsig.com gvSIG Association]
# [[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].
# [[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, Treasurer QGIS Project [http://qgis.org QGIS], Zürich, Switzerland
# [[User:rduivenvoorde| 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]
# [[User: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 member 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]

= 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 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.

== Criticism and Response ==

''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 '''criticism''' of the adoption of the document as an OGC Standard includes a wide variety of reasons such as:

* 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 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:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

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, may be 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.
* [[file:OGC_12-642_GeoServices_REST_API_-_RFC_Comments_Response.pdf|OGC 12-646 Response to RFC Comments]] presents the responses of the Standards Working Group to the comments received from the public during the public Request for Comments (RFC).
* [[file:OGC_13-031r1_GeoServices_REST_API_-_Response_to_no_votes_r1.pdf|OGC 13-031r1 Response to 'no' votes]] presents the responses of the Standards Working Group to the reasons given by the organizations voting _no_ during the adoption 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 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 [http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html 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, not widely enough implemented, 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 =

''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.

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 =
--- DRAFT ____

''Please add concerns not addressed above as bullet points below. Where appropriate, link to external web pages (such as email achieves). Try to be concise, and try not to repeat concepts which have been covered above, (less words get read by more people). Points you have previously added, which are now covered above should be removed. Words that have been struck out will be removed by Tuesday 14 May.''

== Political Concerns ==

== Commercial Concerns ==
* <strike>Supporting multiple overlapping standards greatly reduces usability while it increases complexity and cost of development and maintenance.</strike>
* <strike>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.</strike>
* <strike>Confusing customers with new, overlapping OGC standards will lower the credibility of companies and of OGC, reducing business opportunities.</strike>

== Technical Concerns ==

* 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.
* <strike>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.</strike>
* 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: ''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 ==

# <strike>Ten months after submitting, 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.</strike> (The responses have now been released; see [[#Criticism_and_Response]] above.)
# 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.

A response (from Adrian Custer):

# <strike>The OGC is working to release those documents to the public as of 9 May 2013.</strike> (The documents have now been released; see [[#Criticism_and_Response]] above.)
# 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 some "richer process" for the adoption of a standard; that may be desirable but is not required.

= Further Reading =
''Please add links to referenced documents, related news stories or blog posts here.''
* 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
* 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-15T19:47:46Z

Wiki-Acuster: /* Methodological Concerns */ Respond to comments due to release of the OGC SWG responses.

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.

= 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.

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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go in the "Further Concerns" section below.''

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 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.

== 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
# [[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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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:vehrka|Pedro-Juan Ferrer Matoses]], PM at Omnium Strategic Intelligence, Spain, OSGeo Charter Member, OSGeo Spanish Local Chapter Liaison officer.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[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:Wellsp | Peter Wells]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
# [[User:maurimiranda|Mauricio Miranda]], Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
# [[User:pmachado|Paulo Machado]], Portugal, Software Engineer @ PT Inovação
# [[User:alvaro|Alvaro Anguix]], Spain, General Manager at [http://www.gvsig.com gvSIG Association]
# [[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].
# [[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, Treasurer QGIS Project [http://qgis.org QGIS], Zürich, Switzerland
# [[User:rduivenvoorde| 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]
# [[User: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 member 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]

= 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 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.

== Criticism and Response ==

''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 '''criticism''' of the adoption of the document as an OGC Standard includes a wide variety of reasons such as:

* 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 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:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

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, may be 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.
* [[file:OGC_12-642_GeoServices_REST_API_-_RFC_Comments_Response.pdf|OGC 12-646 Response to RFC Comments]] presents the responses of the Standards Working Group to the comments received from the public during the public Request for Comments (RFC).
* [[file:OGC_13-031r1_GeoServices_REST_API_-_Response_to_no_votes_r1.pdf|OGC 13-031r1 Response to 'no' votes]] presents the responses of the Standards Working Group to the reasons given by the organizations voting _no_ during the adoption 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 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 [http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html 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, not widely enough implemented, 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 =

''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.

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 =
--- DRAFT ____

''Please add concerns not addressed above as bullet points below. Where appropriate, link to external web pages (such as email achieves). Try to be concise, and try not to repeat concepts which have been covered above, (less words get read by more people). Points you have previously added, which are now covered above should be removed. Words that have been struck out will be removed by Tuesday 14 May.''

== Political Concerns ==

== Commercial Concerns ==
* <strike>Supporting multiple overlapping standards greatly reduces usability while it increases complexity and cost of development and maintenance.</strike>
* <strike>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.</strike>
* <strike>Confusing customers with new, overlapping OGC standards will lower the credibility of companies and of OGC, reducing business opportunities.</strike>

== Technical Concerns ==

* 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.
* <strike>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.</strike>
* 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: ''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 ==

# <strike>Ten months after submitting, 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.</strike> (The responses have now been released; see [[#Criticism_and_Response]] above.)
# 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.

A response (from Adrian Custer):

# The OGC is working to release those documents to the public as of 9 May 2013.</strike> (The documents have now been released; see [[#Criticism_and_Response]] above.)
# 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 some "richer process" for the adoption of a standard; that may be desirable but is not required.

= Further Reading =
''Please add links to referenced documents, related news stories or blog posts here.''
* 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
* 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-15T19:37:39Z

Wiki-Acuster: /* Criticism and Response */

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.

= 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.

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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go in the "Further Concerns" section below.''

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 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.

== 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
# [[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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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:vehrka|Pedro-Juan Ferrer Matoses]], PM at Omnium Strategic Intelligence, Spain, OSGeo Charter Member, OSGeo Spanish Local Chapter Liaison officer.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[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:Wellsp | Peter Wells]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
# [[User:maurimiranda|Mauricio Miranda]], Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
# [[User:pmachado|Paulo Machado]], Portugal, Software Engineer @ PT Inovação
# [[User:alvaro|Alvaro Anguix]], Spain, General Manager at [http://www.gvsig.com gvSIG Association]
# [[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].
# [[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, Treasurer QGIS Project [http://qgis.org QGIS], Zürich, Switzerland
# [[User:rduivenvoorde| 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]
# [[User: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 member 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]

= 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 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.

== Criticism and Response ==

''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 '''criticism''' of the adoption of the document as an OGC Standard includes a wide variety of reasons such as:

* 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 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:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

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, may be 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.
* [[file:OGC_12-642_GeoServices_REST_API_-_RFC_Comments_Response.pdf|OGC 12-646 Response to RFC Comments]] presents the responses of the Standards Working Group to the comments received from the public during the public Request for Comments (RFC).
* [[file:OGC_13-031r1_GeoServices_REST_API_-_Response_to_no_votes_r1.pdf|OGC 13-031r1 Response to 'no' votes]] presents the responses of the Standards Working Group to the reasons given by the organizations voting _no_ during the adoption 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 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 [http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html 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, not widely enough implemented, 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 =

''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.

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 =
--- DRAFT ____

''Please add concerns not addressed above as bullet points below. Where appropriate, link to external web pages (such as email achieves). Try to be concise, and try not to repeat concepts which have been covered above, (less words get read by more people). Points you have previously added, which are now covered above should be removed. Words that have been struck out will be removed by Tuesday 14 May.''

== Political Concerns ==

== Commercial Concerns ==
* <strike>Supporting multiple overlapping standards greatly reduces usability while it increases complexity and cost of development and maintenance.</strike>
* <strike>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.</strike>
* <strike>Confusing customers with new, overlapping OGC standards will lower the credibility of companies and of OGC, reducing business opportunities.</strike>

== Technical Concerns ==

* 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.
* <strike>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.</strike>
* 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: ''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 ==

# Ten months after submitting, 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 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.

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 some "richer process" for the adoption of a standard; that may be desirable but is not required.

= Further Reading =
''Please add links to referenced documents, related news stories or blog posts here.''
* 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
* 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-15T19:35:04Z

Wiki-Acuster: /* Criticism and Response */

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.

= 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.

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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go in the "Further Concerns" section below.''

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 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.

== 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
# [[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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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:vehrka|Pedro-Juan Ferrer Matoses]], PM at Omnium Strategic Intelligence, Spain, OSGeo Charter Member, OSGeo Spanish Local Chapter Liaison officer.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[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:Wellsp | Peter Wells]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
# [[User:maurimiranda|Mauricio Miranda]], Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
# [[User:pmachado|Paulo Machado]], Portugal, Software Engineer @ PT Inovação
# [[User:alvaro|Alvaro Anguix]], Spain, General Manager at [http://www.gvsig.com gvSIG Association]
# [[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].
# [[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, Treasurer QGIS Project [http://qgis.org QGIS], Zürich, Switzerland
# [[User:rduivenvoorde| 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]
# [[User: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 member 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]

= 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 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.

== Criticism and Response ==

''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 adoption of the document as an OGC Standard is contentious for a wide variety of reasons including:

* 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 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:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

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, may be 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.
* [[file:OGC_12-642_GeoServices_REST_API_-_RFC_Comments_Response.pdf|OGC 12-646 Response to RFC Comments]] presents the responses of the Standards Working Group to the comments received from the public during the public Request for Comments (RFC).
* [[file:OGC_13-031r1_GeoServices_REST_API_-_Response_to_no_votes_r1.pdf|OGC 13-031r1 Response to 'no' votes]] presents the responses of the Standards Working Group to the reasons given by the organizations voting _no_ during the adoption 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 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 [http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html 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, not widely enough implemented, 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 =

''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.

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 =
--- DRAFT ____

''Please add concerns not addressed above as bullet points below. Where appropriate, link to external web pages (such as email achieves). Try to be concise, and try not to repeat concepts which have been covered above, (less words get read by more people). Points you have previously added, which are now covered above should be removed. Words that have been struck out will be removed by Tuesday 14 May.''

== Political Concerns ==

== Commercial Concerns ==
* <strike>Supporting multiple overlapping standards greatly reduces usability while it increases complexity and cost of development and maintenance.</strike>
* <strike>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.</strike>
* <strike>Confusing customers with new, overlapping OGC standards will lower the credibility of companies and of OGC, reducing business opportunities.</strike>

== Technical Concerns ==

* 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.
* <strike>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.</strike>
* 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: ''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 ==

# Ten months after submitting, 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 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.

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 some "richer process" for the adoption of a standard; that may be desirable but is not required.

= Further Reading =
''Please add links to referenced documents, related news stories or blog posts here.''
* 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
* 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-15T19:21:09Z

Wiki-Acuster: /* Criticism and Response */ Add links to the two response documents now made public by the OGC.

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.

= 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.

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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go in the "Further Concerns" section below.''

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 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.

== 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
# [[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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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:vehrka|Pedro-Juan Ferrer Matoses]], PM at Omnium Strategic Intelligence, Spain, OSGeo Charter Member, OSGeo Spanish Local Chapter Liaison officer.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[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:Wellsp | Peter Wells]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
# [[User:maurimiranda|Mauricio Miranda]], Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
# [[User:pmachado|Paulo Machado]], Portugal, Software Engineer @ PT Inovação
# [[User:alvaro|Alvaro Anguix]], Spain, General Manager at [http://www.gvsig.com gvSIG Association]
# [[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].
# [[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, Treasurer QGIS Project [http://qgis.org QGIS], Zürich, Switzerland
# [[User:rduivenvoorde| 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]
# [[User: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 member 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]

= 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 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.

== Criticism and Response ==

''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 adoption of the document as an OGC Standard is contentious for a wide variety of reasons including:

* 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 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:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

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, may be 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-642_GeoServices_REST_API_-_RFC_Comments_Response.pdf|OGC 12-646 Response to RFC Comments]] presents the responses of the Standards Working Group to the comments received from the public during the public Request for Comments (RFC).
* [[OGC_13-031r1_GeoServices_REST_API_-_Response_to_no_votes_r1.pdf|OGC 13-031r1 Response to 'no' votes]] presents the responses of the Standards Working Group to the reasons given by the organizations voting _no_ during the adoption 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 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 [http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html 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, not widely enough implemented, 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 =

''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.

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 =
--- DRAFT ____

''Please add concerns not addressed above as bullet points below. Where appropriate, link to external web pages (such as email achieves). Try to be concise, and try not to repeat concepts which have been covered above, (less words get read by more people). Points you have previously added, which are now covered above should be removed. Words that have been struck out will be removed by Tuesday 14 May.''

== Political Concerns ==

== Commercial Concerns ==
* <strike>Supporting multiple overlapping standards greatly reduces usability while it increases complexity and cost of development and maintenance.</strike>
* <strike>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.</strike>
* <strike>Confusing customers with new, overlapping OGC standards will lower the credibility of companies and of OGC, reducing business opportunities.</strike>

== Technical Concerns ==

* 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.
* <strike>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.</strike>
* 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: ''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 ==

# Ten months after submitting, 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 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.

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 some "richer process" for the adoption of a standard; that may be desirable but is not required.

= Further Reading =
''Please add links to referenced documents, related news stories or blog posts here.''
* 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
* 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

[[Category: OGC]]
[[Category: Standards]]

File:OGC 13-031r1 GeoServices REST API - Response to no votes r1.pdf

2013-05-15T19:12:47Z

Wiki-Acuster: The response of the Standard Working Group of the OGC proposing the document currently called "GeoServices REST API" to the no votes during the vote for adoption of the document as an OGC Standard.

The response of the Standard Working Group of the OGC proposing the document currently called "GeoServices REST API" to the no votes during the vote for adoption of the document as an OGC Standard.

File:OGC 12-642 GeoServices REST API - RFC Comments Response.pdf

2013-05-15T19:10:20Z

Wiki-Acuster: The Response of the Standards Working Group to the public comments received by the OGC during the public comment period related to the proposed standard currently called "GeoServices REST API".

The Response of the Standards Working Group to the public comments received by the OGC during the public comment period related to the proposed standard currently called "GeoServices REST API".

Geoservices REST API

2013-05-11T02:28:06Z

Wiki-Acuster: /* Methodological Concerns */

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.

= 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.

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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go in the "Further Concerns" section below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[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:Wellsp | Peter Wells]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
# [[User:maurimiranda|Mauricio Miranda]], Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
# [[User:pmachado|Paulo Machado]], Portugal, Software Engineer @ PT Inovação
# [[User:alvaro|Alvaro Anguix]], Spain, General Manager at [http://www.gvsig.com gvSIG Association]
# [[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].

= 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 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.

== Criticism and Response ==

The adoption of the document as an OGC Standard is contentious for a wide variety of reasons including:

* 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 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:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

(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:

* 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, may be 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 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.)

= 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 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 [http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html 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, not widely enough implemented, 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 forwards merely to redouble the efforts to create the next versions of the standards.

= 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.

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 =
--- 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 ==

* 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.
* 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.
* 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 ==

# 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 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 some "richer process" for the adoption of a standard; that may be desirable but is not required.

= Further Reading =
''Please add links to referenced documents, related news stories or blog posts here.''
* 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
* 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-11T02:24:53Z

Wiki-Acuster: /* Criticism and Response */ move back into Summary

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.

= 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.

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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go in the "Further Concerns" section below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[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:Wellsp | Peter Wells]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
# [[User:maurimiranda|Mauricio Miranda]], Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
# [[User:pmachado|Paulo Machado]], Portugal, Software Engineer @ PT Inovação
# [[User:alvaro|Alvaro Anguix]], Spain, General Manager at [http://www.gvsig.com gvSIG Association]
# [[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].

= 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 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.

== Criticism and Response ==

The adoption of the document as an OGC Standard is contentious for a wide variety of reasons including:

* 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 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:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

(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:

* 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, may be 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 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.)

= 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 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 [http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html 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, not widely enough implemented, 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 forwards merely to redouble the efforts to create the next versions of the standards.

= 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.

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 =
--- 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 ==

* 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.
* 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.
* 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 ==

# 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 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 =
''Please add links to referenced documents, related news stories or blog posts here.''
* 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
* 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-11T02:23:40Z

Wiki-Acuster: /* Criticism and Response */ Add locked statement

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.

= 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.

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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go in the "Further Concerns" section below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[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:Wellsp | Peter Wells]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
# [[User:maurimiranda|Mauricio Miranda]], Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
# [[User:pmachado|Paulo Machado]], Portugal, Software Engineer @ PT Inovação
# [[User:alvaro|Alvaro Anguix]], Spain, General Manager at [http://www.gvsig.com gvSIG Association]
# [[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].

= 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 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.

= Criticism and Response =

''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 adoption of the document as an OGC Standard is contentious for a wide variety of reasons including:

* 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 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:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

(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:

* 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, may be 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 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.)

= 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 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 [http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html 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, not widely enough implemented, 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 forwards merely to redouble the efforts to create the next versions of the standards.

= 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.

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 =
--- 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 ==

* 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.
* 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.
* 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 ==

# 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 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 =
''Please add links to referenced documents, related news stories or blog posts here.''
* 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
* 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-11T02:22:28Z

Wiki-Acuster: /* Summary */ Split out the criticism

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.

= 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.

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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go in the "Further Concerns" section below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[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:Wellsp | Peter Wells]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
# [[User:maurimiranda|Mauricio Miranda]], Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
# [[User:pmachado|Paulo Machado]], Portugal, Software Engineer @ PT Inovação
# [[User:alvaro|Alvaro Anguix]], Spain, General Manager at [http://www.gvsig.com gvSIG Association]
# [[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].

= 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 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.

= Criticism and Response =

The adoption of the document as an OGC Standard is contentious for a wide variety of reasons including:

* 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 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:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

(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:

* 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, may be 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 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.)

= 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 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 [http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html 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, not widely enough implemented, 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 forwards merely to redouble the efforts to create the next versions of the standards.

= 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.

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 =
--- 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 ==

* 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.
* 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.
* 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 ==

# 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 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 =
''Please add links to referenced documents, related news stories or blog posts here.''
* 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
* 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-11T02:21:34Z

Wiki-Acuster: /* Positions on the vote */

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.

= 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.

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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go in the "Further Concerns" section below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[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:Wellsp | Peter Wells]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
# [[User:maurimiranda|Mauricio Miranda]], Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
# [[User:pmachado|Paulo Machado]], Portugal, Software Engineer @ PT Inovação
# [[User:alvaro|Alvaro Anguix]], Spain, General Manager at [http://www.gvsig.com gvSIG Association]
# [[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].

= 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 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 adoption of the document as an OGC Standard is contentious for a wide variety of reasons including:

* 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 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:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

(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:

* 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, may be 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 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.)

= 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 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 [http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html 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, not widely enough implemented, 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 forwards merely to redouble the efforts to create the next versions of the standards.

= 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.

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 =
--- 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 ==

* 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.
* 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.
* 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 ==

# 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 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 =
''Please add links to referenced documents, related news stories or blog posts here.''
* 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
* 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-11T02:18:04Z

Wiki-Acuster: /* Positions on the vote */

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.

= 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.

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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go in the "Further Concerns" section below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[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:Wellsp | Peter Wells]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
# [[User:maurimiranda|Mauricio Miranda]], Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
# [[User:pmachado|Paulo Machado]], Portugal, Software Engineer @ PT Inovação
# [[User:alvaro|Alvaro Anguix]], Spain, General Manager at [http://www.gvsig.com gvSIG Association]
# [[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].

= 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 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 adoption of the document as an OGC Standard is contentious for a wide variety of reasons including:

* 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 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:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

(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:

* 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, may be 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 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.)

= 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 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 [http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html 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, not widely enough implemented, 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.
:* 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 rewrite. (see at end)

; 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 forwards merely to redouble the efforts to create the next versions of the standards.

= 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.

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 =
--- 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 ==

* 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.
* 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.
* 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 ==

# 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 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 =
''Please add links to referenced documents, related news stories or blog posts here.''
* 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
* 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-11T02:15:47Z

Wiki-Acuster: /* Positions on the vote */

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.

= 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.

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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go in the "Further Concerns" section below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[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:Wellsp | Peter Wells]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
# [[User:maurimiranda|Mauricio Miranda]], Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
# [[User:pmachado|Paulo Machado]], Portugal, Software Engineer @ PT Inovação
# [[User:alvaro|Alvaro Anguix]], Spain, General Manager at [http://www.gvsig.com gvSIG Association]
# [[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].

= 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 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 adoption of the document as an OGC Standard is contentious for a wide variety of reasons including:

* 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 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:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

(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:

* 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, may be 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 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.)

= 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 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 [http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html 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 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.
:* 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.
:* 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 rewrite. (see at end)

; 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 forwards merely to redouble the efforts to create the next versions of the standards.

= 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.

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 =
--- 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 ==

* 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.
* 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.
* 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 ==

# 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 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 =
''Please add links to referenced documents, related news stories or blog posts here.''
* 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
* 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-11T02:13:27Z

Wiki-Acuster: /* Summary */

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.

= 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.

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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go in the "Further Concerns" section below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[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:Wellsp | Peter Wells]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
# [[User:maurimiranda|Mauricio Miranda]], Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
# [[User:pmachado|Paulo Machado]], Portugal, Software Engineer @ PT Inovação
# [[User:alvaro|Alvaro Anguix]], Spain, General Manager at [http://www.gvsig.com gvSIG Association]
# [[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].

= 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 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 adoption of the document as an OGC Standard is contentious for a wide variety of reasons including:

* 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 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:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

(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:

* 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, may be 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 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.)

= 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 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 [http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html 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 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.
:* 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.
:* 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 rewrite. (see at end)

; 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 forwards merely to redouble the efforts to create the next versions of the standards.

= 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.

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 =
--- 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 ==

* 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.
* 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.
* 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 ==

# 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 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 =
''Please add links to referenced documents, related news stories or blog posts here.''
* 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
* 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-11T02:13:00Z

Wiki-Acuster: /* Summary */

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.

= 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.

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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go in the "Further Concerns" section below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[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:Wellsp | Peter Wells]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
# [[User:maurimiranda|Mauricio Miranda]], Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
# [[User:pmachado|Paulo Machado]], Portugal, Software Engineer @ PT Inovação
# [[User:alvaro|Alvaro Anguix]], Spain, General Manager at [http://www.gvsig.com gvSIG Association]
# [[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].

= 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 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 adoption of the document as an OGC Standard is contentious for a wide variety of reasons including:

* 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 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:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

(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:

* 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, may be 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 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.)

= 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 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 [http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html 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 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.
:* 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.
:* 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 rewrite. (see at end)

; 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 forwards merely to redouble the efforts to create the next versions of the standards.

= 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.

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 =
--- 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 ==

* 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.
* 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.
* 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 ==

# 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 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 =
''Please add links to referenced documents, related news stories or blog posts here.''
* 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
* 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-11T02:10:55Z

Wiki-Acuster: /* Issues with the document */

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.

= 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.

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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go in the "Further Concerns" section below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[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:Wellsp | Peter Wells]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
# [[User:maurimiranda|Mauricio Miranda]], Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
# [[User:pmachado|Paulo Machado]], Portugal, Software Engineer @ PT Inovação
# [[User:alvaro|Alvaro Anguix]], Spain, General Manager at [http://www.gvsig.com gvSIG Association]
# [[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].

= 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 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.

The adoption of the document as an OGC Standard is contentious for a wide variety of reasons including:

* 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 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:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

(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:

* 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, may be 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 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.)

= 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 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 [http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html 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 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.
:* 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.
:* 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 rewrite. (see at end)

; 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 forwards merely to redouble the efforts to create the next versions of the standards.

= 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.

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 =
--- 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 ==

* 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.
* 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.
* 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 ==

# 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 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 =
''Please add links to referenced documents, related news stories or blog posts here.''
* 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
* 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-11T02:09:23Z

Wiki-Acuster: /* Positions on the vote */

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.

= 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.

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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go in the "Further Concerns" section below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[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:Wellsp | Peter Wells]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
# [[User:maurimiranda|Mauricio Miranda]], Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
# [[User:pmachado|Paulo Machado]], Portugal, Software Engineer @ PT Inovação
# [[User:alvaro|Alvaro Anguix]], Spain, General Manager at [http://www.gvsig.com gvSIG Association]
# [[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].

= 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 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.

The adoption of the document as an OGC Standard is contentious for a wide variety of reasons including:

* 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 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:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

(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:

* 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, may be 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 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.)

= 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 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 [http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html 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 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.
:* 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.
:* 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 rewrite. (see at end)

; 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 forwards merely to redouble the efforts to create the next versions of the standards.

= 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 should 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 this 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.

= 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 ==

* 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.
* 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.
* 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 ==

# 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 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 =
''Please add links to referenced documents, related news stories or blog posts here.''
* 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
* 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-11T02:06:56Z

Wiki-Acuster: /* Positions on the vote */

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.

= 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.

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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go in the "Further Concerns" section below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[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:Wellsp | Peter Wells]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
# [[User:maurimiranda|Mauricio Miranda]], Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
# [[User:pmachado|Paulo Machado]], Portugal, Software Engineer @ PT Inovação
# [[User:alvaro|Alvaro Anguix]], Spain, General Manager at [http://www.gvsig.com gvSIG Association]
# [[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].

= 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 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.

The adoption of the document as an OGC Standard is contentious for a wide variety of reasons including:

* 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 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:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

(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:

* 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, may be 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 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.)

= 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 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 [http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html 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 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.
:* 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.
:* 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 rewrite. (see at end)

; 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 forwards merely be to redouble the efforts to create the next versions of the standards.

= 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 should 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 this 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.

= 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 ==

* 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.
* 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.
* 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 ==

# 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 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 =
''Please add links to referenced documents, related news stories or blog posts here.''
* 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
* 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-11T01:52:49Z

Wiki-Acuster: /* Summary */

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.

= 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.

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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go in the "Further Concerns" section below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[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:Wellsp | Peter Wells]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
# [[User:maurimiranda|Mauricio Miranda]], Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
# [[User:pmachado|Paulo Machado]], Portugal, Software Engineer @ PT Inovação
# [[User:alvaro|Alvaro Anguix]], Spain, General Manager at [http://www.gvsig.com gvSIG Association]
# [[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].

= 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 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.

The adoption of the document as an OGC Standard is contentious for a wide variety of reasons including:

* 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 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:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

(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:

* 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, may be 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 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.)

= 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 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 [http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html 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 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.
:* 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.
:* 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 rewrite. (see at end)

; The 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 a third way?

Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to build this thing that we want, an integrated suite of simple services built using simple, well defined resources, accessible and usable using the core HTTP verbs, and discoverable through following links. That's the good way forwards and why to focus work on the next versions of W*S standards (which include JSON bindings), and other modular extensions to OGC services.

= 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 should 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 this 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.

= 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 ==

* 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.
* 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.
* 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 ==

# 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 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 =
''Please add links to referenced documents, related news stories or blog posts here.''
* 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
* 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-11T01:51:59Z

Wiki-Acuster: /* Summary */

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.

= 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.

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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go in the "Further Concerns" section below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[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:Wellsp | Peter Wells]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
# [[User:maurimiranda|Mauricio Miranda]], Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
# [[User:pmachado|Paulo Machado]], Portugal, Software Engineer @ PT Inovação
# [[User:alvaro|Alvaro Anguix]], Spain, General Manager at [http://www.gvsig.com gvSIG Association]
# [[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].

= 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 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.

The adoption of the document as an OGC Standard is contentious for a wide variety of reasons including:

* 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 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:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

(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:

* 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, may be 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 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, those responses will hopefully be presented here as well.)

= 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 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 [http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html 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 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.
:* 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.
:* 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 rewrite. (see at end)

; The 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 a third way?

Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to build this thing that we want, an integrated suite of simple services built using simple, well defined resources, accessible and usable using the core HTTP verbs, and discoverable through following links. That's the good way forwards and why to focus work on the next versions of W*S standards (which include JSON bindings), and other modular extensions to OGC services.

= 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 should 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 this 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.

= 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 ==

* 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.
* 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.
* 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 ==

# 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 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 =
''Please add links to referenced documents, related news stories or blog posts here.''
* 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
* 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-11T01:48:55Z

Wiki-Acuster: /* Summary */

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.

= 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.

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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go in the "Further Concerns" section below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[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:Wellsp | Peter Wells]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
# [[User:maurimiranda|Mauricio Miranda]], Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
# [[User:pmachado|Paulo Machado]], Portugal, Software Engineer @ PT Inovação
# [[User:alvaro|Alvaro Anguix]], Spain, General Manager at [http://www.gvsig.com gvSIG Association]
# [[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].

= 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 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.

The adoption of the document is contentious for a wide variety of reasons including:

* 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 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:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

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, may be 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 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, those responses will hopefully be presented here as well.)

= 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 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 [http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html 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 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.
:* 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.
:* 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 rewrite. (see at end)

; The 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 a third way?

Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to build this thing that we want, an integrated suite of simple services built using simple, well defined resources, accessible and usable using the core HTTP verbs, and discoverable through following links. That's the good way forwards and why to focus work on the next versions of W*S standards (which include JSON bindings), and other modular extensions to OGC services.

= 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 should 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 this 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.

= 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 ==

* 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.
* 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.
* 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 ==

# 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 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 =
''Please add links to referenced documents, related news stories or blog posts here.''
* 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
* 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-11T01:24:30Z

Wiki-Acuster: /* Summary */ Update the critique to flesh out explanation

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.

= 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.

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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go in the "Further Concerns" section below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[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:Wellsp | Peter Wells]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], Co-Founder
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member
# [[User:maurimiranda|Mauricio Miranda]], Argentina, OSGeo Charter Member, OSGeo Spanish Local Chapter Board Member
# [[User:pmachado|Paulo Machado]], Portugal, Software Engineer @ PT Inovação
# [[User:alvaro|Alvaro Anguix]], Spain, General Manager at [http://www.gvsig.com gvSIG Association]
# [[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].

= 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 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.

The adoption of the document is contentious for a wide variety of reasons including:

* the process through which the document was developed which was 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 implementation an unusual commercial advantage on top of the vendor's 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:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

These issues have been answered by the authors of the Geoservices REST API document who state:

* 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, may be 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, that the standardization of the services at the OGC may encourage new implementations,

= 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 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 [http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html 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 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.
:* 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.
:* 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 rewrite. (see at end)

; The 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 a third way?

Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to build this thing that we want, an integrated suite of simple services built using simple, well defined resources, accessible and usable using the core HTTP verbs, and discoverable through following links. That's the good way forwards and why to focus work on the next versions of W*S standards (which include JSON bindings), and other modular extensions to OGC services.

= 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 should 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 this 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.

= 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 ==

* 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.
* 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.
* 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 ==

# 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 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 =
''Please add links to referenced documents, related news stories or blog posts here.''
* 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
* 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-10T16:43:09Z

Wiki-Acuster: /* Issues with the document */

This wiki 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 is being collaboratively edited, targeting completion before the end of May 2013.

= 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, which 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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[User:Hfpmartins | Hugo Martins]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], WebGIS Developer, OSGeo-Portugal Member
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member

= Summary =

The document titled "GeoServices REST API" is currently, in May 2013, being considered as a standard of the Open Geospatial Consortium (OGC). 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.

The adoption of the document is contentious for a wide variety of reasons including:

* the process through which it was developed,
* the language of 'REST' and 'API' used by the document,
* the names of the standard and of the services which are potentially confusing
* the duplication of these new services with other services standardized by the OGC such as WMS, WFS, WCS, and WPS and with work, by those services, of adopting RESTful designs including URL hierarchies and JSON exchange formats,
* the specific format of JSON messages used, and
* the dominance of the vendor of the single complete implementation in the marketplace.

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 of 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 is a feel that adoption of the standard will likely result in a combination of the following:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

These issues have been answered by the authors of the document who state:

* 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, may be 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 of some of these services.

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

= Positions on the vote =

The discussion raises a number of issues even beyond those mentioned above. This makes difficult any rational decision by the voting members of the OGC Technical Committee, who will determine adoption or rejection of the vote.

The following is the analysis of positions on the vote, originally from a single person on his own point of view and therefore reaching a conclusion appropriate in particular to him. Obviously the signatories of the letter at the start of this page have reached different conclusions.

; The pros:

:* The OGC should be in the business of developing good standards, not of choosing which standards should be implemented.
:* The proposers of the document want to make a standard and have followed all the rules of the consortium. 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 an author of standards at the OGC, 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 is, de-facto, in the position of recommending the 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.
:* Adopting a standard implies a desire to maintain the standard, but the desire to support this approach by the OGC membership is limited. The lack of collaboration on this version 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 implemetation.
:* 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 rewrite. (see at end)

; The 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. (On that, perhaps they should be allowed to make their own mistakes.) The path forwards towards harmonizing the services is unclear. There is little good will towards the standard on behalf of the membership. 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 a third way?

Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to build this thing that we want, an integrated suite of simple services built using simple, well defined resources, accessible and usable using the core HTTP verbs, and discoverable through following links. That's the good way forwards and why to focus work on WMS-Next, WCS JSON bindings, and other modular extensions to OGC services.

= Issues with the document =

Beyond the controversy described above, there are issues with the standard 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.

The critique can be found on the separate [[Geoservices_REST_API_critique]] page.

Note that some of these critiques hold the document to the current, higher standard of the OGC. 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.

= Further Concerns =
--- DRAFT ____

''Please add concerns as bullet points below. Try to be concise. 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 ==

* 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.
* 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.
* 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 ==

# 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 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.

= References =
* 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
* Adrian Custer's eloquent, unbiased, concise summary of the technical issues: 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-10T16:41:42Z

Wiki-Acuster: /* Summary */

This wiki 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 is being collaboratively edited, targeting completion before the end of May 2013.

= 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, which 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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[User:Hfpmartins | Hugo Martins]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], WebGIS Developer, OSGeo-Portugal Member
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member

= Summary =

The document titled "GeoServices REST API" is currently, in May 2013, being considered as a standard of the Open Geospatial Consortium (OGC). 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.

The adoption of the document is contentious for a wide variety of reasons including:

* the process through which it was developed,
* the language of 'REST' and 'API' used by the document,
* the names of the standard and of the services which are potentially confusing
* the duplication of these new services with other services standardized by the OGC such as WMS, WFS, WCS, and WPS and with work, by those services, of adopting RESTful designs including URL hierarchies and JSON exchange formats,
* the specific format of JSON messages used, and
* the dominance of the vendor of the single complete implementation in the marketplace.

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 of 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 is a feel that adoption of the standard will likely result in a combination of the following:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

These issues have been answered by the authors of the document who state:

* 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, may be 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 of some of these services.

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

= Positions on the vote =

The discussion raises a number of issues even beyond those mentioned above. This makes difficult any rational decision by the voting members of the OGC Technical Committee, who will determine adoption or rejection of the vote.

The following is the analysis of positions on the vote, originally from a single person on his own point of view and therefore reaching a conclusion appropriate in particular to him. Obviously the signatories of the letter at the start of this page have reached different conclusions.

; The pros:

:* The OGC should be in the business of developing good standards, not of choosing which standards should be implemented.
:* The proposers of the document want to make a standard and have followed all the rules of the consortium. 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 an author of standards at the OGC, 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 is, de-facto, in the position of recommending the 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.
:* Adopting a standard implies a desire to maintain the standard, but the desire to support this approach by the OGC membership is limited. The lack of collaboration on this version 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 implemetation.
:* 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 rewrite. (see at end)

; The 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. (On that, perhaps they should be allowed to make their own mistakes.) The path forwards towards harmonizing the services is unclear. There is little good will towards the standard on behalf of the membership. 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 a third way?

Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to build this thing that we want, an integrated suite of simple services built using simple, well defined resources, accessible and usable using the core HTTP verbs, and discoverable through following links. That's the good way forwards and why to focus work on WMS-Next, WCS JSON bindings, and other modular extensions to OGC services.

= Issues with the document =

Beyond the controversy describe above, there are issues with the standard 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.

The critique can be found on the separate [[Geoservices_REST_API_critique]] page.

Note that some of these critiques hold the document to the current, higher standard of the OGC. 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.

= Further Concerns =
--- DRAFT ____

''Please add concerns as bullet points below. Try to be concise. 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 ==

* 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.
* 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.
* 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 ==

# 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 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.

= References =
* 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
* Adrian Custer's eloquent, unbiased, concise summary of the technical issues: 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-10T16:40:42Z

Wiki-Acuster: /* Summary */

This wiki 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 is being collaboratively edited, targeting completion before the end of May 2013.

= 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, which 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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[User:Hfpmartins | Hugo Martins]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], WebGIS Developer, OSGeo-Portugal Member
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member

= Summary =

The document titled "GeoServices REST API" is currently, in May 2013, being considered as a standard of the Open Geospatial Consortium (OGC). 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.

The adoption of the document is contentious for a wide variety of reasons including:

* the process through which it was developed,
* the language of 'REST' and 'API' used by the document,
* the names of the standard and of the services is confusing
* the duplication of these new services with other services standardized by the OGC such as WMS, WFS, WCS, and WPS and with work, by those services, of adopting RESTful designs including URL hierarchies and JSON exchange formats,
* the specific format of JSON messages used, and
* the dominance of the vendor of the single complete implementation in the marketplace.

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 of 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 is a feel that adoption of the standard will likely result in a combination of the following:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

These issues have been answered by the authors of the document who state:

* 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, may be 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 of some of these services.

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

= Positions on the vote =

The discussion raises a number of issues even beyond those mentioned above. This makes difficult any rational decision by the voting members of the OGC Technical Committee, who will determine adoption or rejection of the vote.

The following is the analysis of positions on the vote, originally from a single person on his own point of view and therefore reaching a conclusion appropriate in particular to him. Obviously the signatories of the letter at the start of this page have reached different conclusions.

; The pros:

:* The OGC should be in the business of developing good standards, not of choosing which standards should be implemented.
:* The proposers of the document want to make a standard and have followed all the rules of the consortium. 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 an author of standards at the OGC, 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 is, de-facto, in the position of recommending the 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.
:* Adopting a standard implies a desire to maintain the standard, but the desire to support this approach by the OGC membership is limited. The lack of collaboration on this version 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 implemetation.
:* 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 rewrite. (see at end)

; The 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. (On that, perhaps they should be allowed to make their own mistakes.) The path forwards towards harmonizing the services is unclear. There is little good will towards the standard on behalf of the membership. 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 a third way?

Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to build this thing that we want, an integrated suite of simple services built using simple, well defined resources, accessible and usable using the core HTTP verbs, and discoverable through following links. That's the good way forwards and why to focus work on WMS-Next, WCS JSON bindings, and other modular extensions to OGC services.

= Issues with the document =

Beyond the controversy describe above, there are issues with the standard 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.

The critique can be found on the separate [[Geoservices_REST_API_critique]] page.

Note that some of these critiques hold the document to the current, higher standard of the OGC. 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.

= Further Concerns =
--- DRAFT ____

''Please add concerns as bullet points below. Try to be concise. 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 ==

* 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.
* 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.
* 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 ==

# 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 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.

= References =
* 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
* Adrian Custer's eloquent, unbiased, concise summary of the technical issues: 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-10T16:39:16Z

Wiki-Acuster: Tweak intro sentence

This wiki 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 is being collaboratively edited, targeting completion before the end of May 2013.

= 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, which 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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[User:Hfpmartins | Hugo Martins]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], WebGIS Developer, OSGeo-Portugal Member
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member

= Summary =

The document titled "GeoServices REST API" is currently, in May 2013, being considered as a standard of the Open Geospatial Consortium (OGC). 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 JSON format.

The adoption of the document is contentious for a wide variety of reasons including:

* the process through which it was developed,
* the language of 'REST' and 'API' used by the document,
* the names of the standard and of the services is confusing
* the duplication of these new services with other services standardized by the OGC such as WMS, WFS, WCS, and WPS and with work, by those services, of adopting RESTful designs including URL hierarchies and JSON exchange formats,
* the specific format of JSON messages used, and
* the dominance of the vendor of the single complete implementation in the marketplace.

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 of 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 is a feel that adoption of the standard will likely result in a combination of the following:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

These issues have been answered by the authors of the document who state:

* 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, may be 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 of some of these services.

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

= Positions on the vote =

The discussion raises a number of issues even beyond those mentioned above. This makes difficult any rational decision by the voting members of the OGC Technical Committee, who will determine adoption or rejection of the vote.

The following is the analysis of positions on the vote, originally from a single person on his own point of view and therefore reaching a conclusion appropriate in particular to him. Obviously the signatories of the letter at the start of this page have reached different conclusions.

; The pros:

:* The OGC should be in the business of developing good standards, not of choosing which standards should be implemented.
:* The proposers of the document want to make a standard and have followed all the rules of the consortium. 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 an author of standards at the OGC, 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 is, de-facto, in the position of recommending the 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.
:* Adopting a standard implies a desire to maintain the standard, but the desire to support this approach by the OGC membership is limited. The lack of collaboration on this version 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 implemetation.
:* 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 rewrite. (see at end)

; The 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. (On that, perhaps they should be allowed to make their own mistakes.) The path forwards towards harmonizing the services is unclear. There is little good will towards the standard on behalf of the membership. 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 a third way?

Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to build this thing that we want, an integrated suite of simple services built using simple, well defined resources, accessible and usable using the core HTTP verbs, and discoverable through following links. That's the good way forwards and why to focus work on WMS-Next, WCS JSON bindings, and other modular extensions to OGC services.

= Issues with the document =

Beyond the controversy describe above, there are issues with the standard 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.

The critique can be found on the separate [[Geoservices_REST_API_critique]] page.

Note that some of these critiques hold the document to the current, higher standard of the OGC. 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.

= Further Concerns =
--- DRAFT ____

''Please add concerns as bullet points below. Try to be concise. 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 ==

* 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.
* 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.
* 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 ==

# 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 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.

= References =
* 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
* Adrian Custer's eloquent, unbiased, concise summary of the technical issues: 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API critique

2013-05-10T16:37:47Z

Wiki-Acuster: /* A Critique of the proposed "GeoServices REST API" document */

= A Critique of the proposed "GeoServices REST API" document =

The document "GeoServices REST API" has proposed for adoption as a standard of the Open Geospatial Consortium (OGC). This has generated extensive controversy, discussed on the [[Geoservices_REST_API]] page.

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

This critique is incomplete because it quickly falls into a full editorial review of the text, something which takes a lot of time and effort.

Note that some of these critiques hold the document to the current, higher standard of the OGC. 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.

==The name==

The document currently uses a name that is confusing in all discussions on the matter, both internally at the OGC and externally.

(Postnote 9 May 2013: the Standards Working Group proposing the document agreed to accept proposals for new names; if they can find a good alternative, they may adopt it.)

==The design==

The document does not show an overall, coherent design to the service suite. This is mostly because the design reflects a suite that [initially] evolved piecemeal at ESRI rather than one designed from the start to meet the needs of a broad swath of users. This is also due because the experts at the OGC did not contribute to an improved design for a multitude of reasons.

The design of the service which does exist is focused on yesteryear. As an apology for the existing design, section~6.2.2 of part 1, Core says that the only HTTP verbs used are GET and PUT because "the API was originally developed several years ago" but that's okay because it enables support for "Microsoft Silverlight" and "Adobe Flex" two standards which are dying rapidly. In 2013, a new standard ought to be focused on the next 10 years not the past ten.

==The writing==

The document is poorly written.

===The document is poorly introduced===

The document should start with a discussion of the overall design of the suite of services and what each individual service provides within that suite. This would make it easy for a user to understand the focus of the suite. (The note between requirements~3 and requirement~4, stating that the spec makes no requirements on clients, is really part of the scope of the document and should be front and center.)

The document instead starts with a whole section on REST.

: 1. Scope
: The GeoServices REST API provides a standard way for web clients to communicate with geographic information system (GIS) servers based on Representational State Transfer (REST) principles.

The scope claims that the document identifies resources and a way to use "structured URLs" to exchange those resources between clients and services. If that were true, I would expect
: (1) a list of resources at least as an example, and
: (2) an example of the structure and structuring principles of the URLs.

Section~6 stats this process. Section~6.1 introduces the concept of a root URL for each service and mixes in that that root URL is also a catalog and that the hierarchy offers resources. This all happens in a single, overly compact paragraph. This section needs an editorial rewrite for clarity separating
: (1) the end point,
: (2) the catalog,
: (3) the URL hierarchy,
: (4) the resources, and
: (5) interaction of clients with the URLs through the exchange (get/post) of the resources to the different URLs.

Unfortunately, section~6 then decays into a meandering discussion of REST which mentions the buzzword a lot but does not discuss the aspects of REST design that have been met by the suite and those that have not. If REST is a form of design which offers certain benefits, OGC standards should be discussing the benefits achieved not the buzz word. To what extent are the resources cachable and how do clients and servers agree on that? To what extent are the endpoints and actions on those endpoints discoverable, and how? Those are the issues of RESTful design.

Section~6.3 discusses Resources but immediately then states:

: Each resource has a unique URL. Resources MAY support parameters.

which is a discussion of the URL hierarchy. (And 'Resources' do not 'support parameters'! Services may 'handle requests containing parameters' if that is what is meant.) Then the standard introduces a new idea 'Controller Resources' which are able to 'edit' and 'query'!? A web search does not reveal any formal discussion of 'Controller Resource' so this new type of resource probably deserves some kind of formal introduction.

Section~6.3.3 is not really about resources but the fact that the URL hierarchy is not discoverable from the Resources themselves.

Section~6.3.4 does give a list of resources, but since 'image' is not part of it but will be used by the Service for Map Images, I surmise that the list is of the things 'we have designed a JSON representation for' rather than a list of 'the resources identified and exchanged in the service suite' which is what I expect in an introductory design.

This introduction therefore needs a substantial editorial rewrite to be effective in its goal of explaining what the suite of standards actually does.

This criticism is not limited to the core document.

The Service for Maps document also starts without setting out the five core elements (end pt, catalog?, URL hierarchy, resources, and interactions).

Section~6 of the Service for Maps part, in the middle of the second paragraph, introduces a new concept, with capitalized letters:

: The Map Service Root resource includes a tables property ...

without giving us any clue what this is. It "provides basic information" (perhaps it is a data structure?) but it also "supports several operations" (maybe it's a magical 'Controller Resource'). To me, this just reads as 'the authors of the spec are confused and imprecise in their written language'.

Then, in the figure of 'Resources,' there is actually a resource called 'All layers and tables'. Sorry, but this reader needs some real help to understand what that resource might be.

=== The document requirements are poor ===

The very first requirement, Requirement~1 of the Core document, states:

: Req 1 If a request uses the HTTP GET method, the processing of the request by the service SHALL be safe and idempotent as specified by RFC 2616, 9.1.

This is a *ridiculous* requirement, completely untestable, and explicitly what the Mod Spec should be preventing with its attempt to require all injunctive language to be accompanied by formal tests. The formal test indeed shows that the requirement is untestable.

: Inspect the documentation of the implementation to identify, if requests specified in the GeoServices REST API standard that support the HTTP GET method, are all safe and idempotent, i.e. free of side- effects, as specified in HTTP (RFC 2616, section 9.1). Alternatively, ask the developer of the the service.

: Note that it is not possible to run automated tests against a service to verify conformance with the requirement (and IETF provides no test for conformance with HTTP either). In the absence of such tests, a statement of the developers of the service is sufficient indication that the requirement was addressed.

So essentially this requirement is met if the developers say 'yeah, we thought about it.' In other words, requirement 1 of the whole shebang is a recommendation. Contrast this with requirement 2 which has a nice test defined for it and is a good, solid requirement.

Again, broadening the critique to the Services for Maps, its first requirement states:

: Req 1 The Map Service Root resource SHALL accept requests that conform to the URI template in Table and use any HTTP method identified in the same table.

but the test is then completely irrelevant. At the protocol level, all web services 'shall accept' request messages, so we are not discussing that. A functional test for this 'shall accept' is to construct all valid requests and see that the service never returns an exception to those requests. Even worse, the first test is a catch all 'please test the service here' test. This is *not* a well written specification of the tests for the injunctions of the Service for Maps.

The requirements need a complete, systematic review to see that they work, they are testable, and have good tests.

=== The document has numerous other issues which need resolution ===

* There is no discussion of the overlap of the f= parameter and of the HTTP format header. What happens if they conflict?
* The lack of full integration of the four core HTTP verbs, notably DELETE and PUT, exists merely for backwards compatibility not for forwards progress.
* Requirement~3 blocks forwards progress and experimentation with no explanation as to its importance.
* This goes on and on. This is the work for an EDITOR. I am not interested in doing that work.

Geoservices REST API

2013-05-10T16:37:34Z

Wiki-Acuster: /* Issues with the document */

This wiki page aims to collate community concerns related to the proposed acceptance of the "Geoservices REST API" becoming an OGC standard. It is being collaboratively edited, targeting completion before the end of May 2013.

= 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, which 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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[User:Hfpmartins | Hugo Martins]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], WebGIS Developer, OSGeo-Portugal Member
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member

= Summary =

The document titled "GeoServices REST API" is currently, in May 2013, being considered as a standard of the Open Geospatial Consortium (OGC). 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 JSON format.

The adoption of the document is contentious for a wide variety of reasons including:

* the process through which it was developed,
* the language of 'REST' and 'API' used by the document,
* the names of the standard and of the services is confusing
* the duplication of these new services with other services standardized by the OGC such as WMS, WFS, WCS, and WPS and with work, by those services, of adopting RESTful designs including URL hierarchies and JSON exchange formats,
* the specific format of JSON messages used, and
* the dominance of the vendor of the single complete implementation in the marketplace.

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 of 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 is a feel that adoption of the standard will likely result in a combination of the following:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

These issues have been answered by the authors of the document who state:

* 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, may be 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 of some of these services.

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

= Positions on the vote =

The discussion raises a number of issues even beyond those mentioned above. This makes difficult any rational decision by the voting members of the OGC Technical Committee, who will determine adoption or rejection of the vote.

The following is the analysis of positions on the vote, originally from a single person on his own point of view and therefore reaching a conclusion appropriate in particular to him. Obviously the signatories of the letter at the start of this page have reached different conclusions.

; The pros:

:* The OGC should be in the business of developing good standards, not of choosing which standards should be implemented.
:* The proposers of the document want to make a standard and have followed all the rules of the consortium. 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 an author of standards at the OGC, 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 is, de-facto, in the position of recommending the 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.
:* Adopting a standard implies a desire to maintain the standard, but the desire to support this approach by the OGC membership is limited. The lack of collaboration on this version 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 implemetation.
:* 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 rewrite. (see at end)

; The 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. (On that, perhaps they should be allowed to make their own mistakes.) The path forwards towards harmonizing the services is unclear. There is little good will towards the standard on behalf of the membership. 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 a third way?

Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to build this thing that we want, an integrated suite of simple services built using simple, well defined resources, accessible and usable using the core HTTP verbs, and discoverable through following links. That's the good way forwards and why to focus work on WMS-Next, WCS JSON bindings, and other modular extensions to OGC services.

= Issues with the document =

Beyond the controversy describe above, there are issues with the standard 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.

The critique can be found on the separate [[Geoservices_REST_API_critique]] page.

Note that some of these critiques hold the document to the current, higher standard of the OGC. 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.

= Further Concerns =
--- DRAFT ____

''Please add concerns as bullet points below. Try to be concise. 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 ==

* 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.
* 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.
* 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 ==

# 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 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.

= References =
* 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
* Adrian Custer's eloquent, unbiased, concise summary of the technical issues: 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API critique

2013-05-10T16:35:27Z

Wiki-Acuster: Add the page

= A Critique of the proposed "GeoServices REST API" document =

The document "GeoServices REST API" has proposed for adoption as a standard of the Open Geospatial Consortium (OGC). This has generated extensive controversy, discussed on the [[Geoservices_REST_API]] page.

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

This critique is incomplete because it quickly falls into a full editorial review of the text, something which takes a lot of time and effort.

Note that these critiques hold the document to the current, higher standard of the OGC.

==The name==

The document currently uses a name that is confusing in all discussions on the matter, both internally at the OGC and externally.

(Postnote 9 May 2013: the Standards Working Group proposing the document agreed to accept proposals for new names; if they can find a good alternative, they may adopt it.)

==The design==

The document does not show an overall, coherent design to the service suite. This is mostly because the design reflects a suite that [initially] evolved piecemeal at ESRI rather than one designed from the start to meet the needs of a broad swath of users. This is also due because the experts at the OGC did not contribute to an improved design for a multitude of reasons.

The design of the service which does exist is focused on yesteryear. As an apology for the existing design, section~6.2.2 of part 1, Core says that the only HTTP verbs used are GET and PUT because "the API was originally developed several years ago" but that's okay because it enables support for "Microsoft Silverlight" and "Adobe Flex" two standards which are dying rapidly. In 2013, a new standard ought to be focused on the next 10 years not the past ten.

==The writing==

The document is poorly written.

===The document is poorly introduced===

The document should start with a discussion of the overall design of the suite of services and what each individual service provides within that suite. This would make it easy for a user to understand the focus of the suite. (The note between requirements~3 and requirement~4, stating that the spec makes no requirements on clients, is really part of the scope of the document and should be front and center.)

The document instead starts with a whole section on REST.

: 1. Scope
: The GeoServices REST API provides a standard way for web clients to communicate with geographic information system (GIS) servers based on Representational State Transfer (REST) principles.

The scope claims that the document identifies resources and a way to use "structured URLs" to exchange those resources between clients and services. If that were true, I would expect
: (1) a list of resources at least as an example, and
: (2) an example of the structure and structuring principles of the URLs.

Section~6 stats this process. Section~6.1 introduces the concept of a root URL for each service and mixes in that that root URL is also a catalog and that the hierarchy offers resources. This all happens in a single, overly compact paragraph. This section needs an editorial rewrite for clarity separating
: (1) the end point,
: (2) the catalog,
: (3) the URL hierarchy,
: (4) the resources, and
: (5) interaction of clients with the URLs through the exchange (get/post) of the resources to the different URLs.

Unfortunately, section~6 then decays into a meandering discussion of REST which mentions the buzzword a lot but does not discuss the aspects of REST design that have been met by the suite and those that have not. If REST is a form of design which offers certain benefits, OGC standards should be discussing the benefits achieved not the buzz word. To what extent are the resources cachable and how do clients and servers agree on that? To what extent are the endpoints and actions on those endpoints discoverable, and how? Those are the issues of RESTful design.

Section~6.3 discusses Resources but immediately then states:

: Each resource has a unique URL. Resources MAY support parameters.

which is a discussion of the URL hierarchy. (And 'Resources' do not 'support parameters'! Services may 'handle requests containing parameters' if that is what is meant.) Then the standard introduces a new idea 'Controller Resources' which are able to 'edit' and 'query'!? A web search does not reveal any formal discussion of 'Controller Resource' so this new type of resource probably deserves some kind of formal introduction.

Section~6.3.3 is not really about resources but the fact that the URL hierarchy is not discoverable from the Resources themselves.

Section~6.3.4 does give a list of resources, but since 'image' is not part of it but will be used by the Service for Map Images, I surmise that the list is of the things 'we have designed a JSON representation for' rather than a list of 'the resources identified and exchanged in the service suite' which is what I expect in an introductory design.

This introduction therefore needs a substantial editorial rewrite to be effective in its goal of explaining what the suite of standards actually does.

This criticism is not limited to the core document.

The Service for Maps document also starts without setting out the five core elements (end pt, catalog?, URL hierarchy, resources, and interactions).

Section~6 of the Service for Maps part, in the middle of the second paragraph, introduces a new concept, with capitalized letters:

: The Map Service Root resource includes a tables property ...

without giving us any clue what this is. It "provides basic information" (perhaps it is a data structure?) but it also "supports several operations" (maybe it's a magical 'Controller Resource'). To me, this just reads as 'the authors of the spec are confused and imprecise in their written language'.

Then, in the figure of 'Resources,' there is actually a resource called 'All layers and tables'. Sorry, but this reader needs some real help to understand what that resource might be.

=== The document requirements are poor ===

The very first requirement, Requirement~1 of the Core document, states:

: Req 1 If a request uses the HTTP GET method, the processing of the request by the service SHALL be safe and idempotent as specified by RFC 2616, 9.1.

This is a *ridiculous* requirement, completely untestable, and explicitly what the Mod Spec should be preventing with its attempt to require all injunctive language to be accompanied by formal tests. The formal test indeed shows that the requirement is untestable.

: Inspect the documentation of the implementation to identify, if requests specified in the GeoServices REST API standard that support the HTTP GET method, are all safe and idempotent, i.e. free of side- effects, as specified in HTTP (RFC 2616, section 9.1). Alternatively, ask the developer of the the service.

: Note that it is not possible to run automated tests against a service to verify conformance with the requirement (and IETF provides no test for conformance with HTTP either). In the absence of such tests, a statement of the developers of the service is sufficient indication that the requirement was addressed.

So essentially this requirement is met if the developers say 'yeah, we thought about it.' In other words, requirement 1 of the whole shebang is a recommendation. Contrast this with requirement 2 which has a nice test defined for it and is a good, solid requirement.

Again, broadening the critique to the Services for Maps, its first requirement states:

: Req 1 The Map Service Root resource SHALL accept requests that conform to the URI template in Table and use any HTTP method identified in the same table.

but the test is then completely irrelevant. At the protocol level, all web services 'shall accept' request messages, so we are not discussing that. A functional test for this 'shall accept' is to construct all valid requests and see that the service never returns an exception to those requests. Even worse, the first test is a catch all 'please test the service here' test. This is *not* a well written specification of the tests for the injunctions of the Service for Maps.

The requirements need a complete, systematic review to see that they work, they are testable, and have good tests.

=== The document has numerous other issues which need resolution ===

* There is no discussion of the overlap of the f= parameter and of the HTTP format header. What happens if they conflict?
* The lack of full integration of the four core HTTP verbs, notably DELETE and PUT, exists merely for backwards compatibility not for forwards progress.
* Requirement~3 blocks forwards progress and experimentation with no explanation as to its importance.
* This goes on and on. This is the work for an EDITOR. I am not interested in doing that work.

Geoservices REST API

2013-05-10T16:31:20Z

Wiki-Acuster: Split document critque to new page

This wiki page aims to collate community concerns related to the proposed acceptance of the "Geoservices REST API" becoming an OGC standard. It is being collaboratively edited, targeting completion before the end of May 2013.

= 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, which 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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[User:Hfpmartins | Hugo Martins]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], WebGIS Developer, OSGeo-Portugal Member
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member

= Summary =

The document titled "GeoServices REST API" is currently, in May 2013, being considered as a standard of the Open Geospatial Consortium (OGC). 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 JSON format.

The adoption of the document is contentious for a wide variety of reasons including:

* the process through which it was developed,
* the language of 'REST' and 'API' used by the document,
* the names of the standard and of the services is confusing
* the duplication of these new services with other services standardized by the OGC such as WMS, WFS, WCS, and WPS and with work, by those services, of adopting RESTful designs including URL hierarchies and JSON exchange formats,
* the specific format of JSON messages used, and
* the dominance of the vendor of the single complete implementation in the marketplace.

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 of 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 is a feel that adoption of the standard will likely result in a combination of the following:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

These issues have been answered by the authors of the document who state:

* 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, may be 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 of some of these services.

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

= Positions on the vote =

The discussion raises a number of issues even beyond those mentioned above. This makes difficult any rational decision by the voting members of the OGC Technical Committee, who will determine adoption or rejection of the vote.

The following is the analysis of positions on the vote, originally from a single person on his own point of view and therefore reaching a conclusion appropriate in particular to him. Obviously the signatories of the letter at the start of this page have reached different conclusions.

; The pros:

:* The OGC should be in the business of developing good standards, not of choosing which standards should be implemented.
:* The proposers of the document want to make a standard and have followed all the rules of the consortium. 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 an author of standards at the OGC, 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 is, de-facto, in the position of recommending the 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.
:* Adopting a standard implies a desire to maintain the standard, but the desire to support this approach by the OGC membership is limited. The lack of collaboration on this version 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 implemetation.
:* 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 rewrite. (see at end)

; The 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. (On that, perhaps they should be allowed to make their own mistakes.) The path forwards towards harmonizing the services is unclear. There is little good will towards the standard on behalf of the membership. 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 a third way?

Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to build this thing that we want, an integrated suite of simple services built using simple, well defined resources, accessible and usable using the core HTTP verbs, and discoverable through following links. That's the good way forwards and why to focus work on WMS-Next, WCS JSON bindings, and other modular extensions to OGC services.

= Issues with the document =

Beyond the controversy describe above, there are issues with the standard 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.

The critique can be found on the separate [[Geoservices_REST_API_critique]] page.

= Further Concerns =
--- DRAFT ____

''Please add concerns as bullet points below. Try to be concise. 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 ==

* 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.
* 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.
* 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 ==

# 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 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.

= References =
* 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
* Adrian Custer's eloquent, unbiased, concise summary of the technical issues: 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-10T16:29:37Z

Wiki-Acuster: /* Issues with the document */

This wiki page aims to collate community concerns related to the proposed acceptance of the "Geoservices REST API" becoming an OGC standard. It is being collaboratively edited, targeting completion before the end of May 2013.

= 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, which 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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[User:Hfpmartins | Hugo Martins]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], WebGIS Developer, OSGeo-Portugal Member
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member

= Summary =

The document titled "GeoServices REST API" is currently, in May 2013, being considered as a standard of the Open Geospatial Consortium (OGC). 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 JSON format.

The adoption of the document is contentious for a wide variety of reasons including:

* the process through which it was developed,
* the language of 'REST' and 'API' used by the document,
* the names of the standard and of the services is confusing
* the duplication of these new services with other services standardized by the OGC such as WMS, WFS, WCS, and WPS and with work, by those services, of adopting RESTful designs including URL hierarchies and JSON exchange formats,
* the specific format of JSON messages used, and
* the dominance of the vendor of the single complete implementation in the marketplace.

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 of 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 is a feel that adoption of the standard will likely result in a combination of the following:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

These issues have been answered by the authors of the document who state:

* 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, may be 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 of some of these services.

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

= Positions on the vote =

The discussion raises a number of issues even beyond those mentioned above. This makes difficult any rational decision by the voting members of the OGC Technical Committee, who will determine adoption or rejection of the vote.

The following is the analysis of positions on the vote, originally from a single person on his own point of view and therefore reaching a conclusion appropriate in particular to him. Obviously the signatories of the letter at the start of this page have reached different conclusions.

; The pros:

:* The OGC should be in the business of developing good standards, not of choosing which standards should be implemented.
:* The proposers of the document want to make a standard and have followed all the rules of the consortium. 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 an author of standards at the OGC, 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 is, de-facto, in the position of recommending the 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.
:* Adopting a standard implies a desire to maintain the standard, but the desire to support this approach by the OGC membership is limited. The lack of collaboration on this version 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 implemetation.
:* 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 rewrite. (see at end)

; The 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. (On that, perhaps they should be allowed to make their own mistakes.) The path forwards towards harmonizing the services is unclear. There is little good will towards the standard on behalf of the membership. 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 a third way?

Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to build this thing that we want, an integrated suite of simple services built using simple, well defined resources, accessible and usable using the core HTTP verbs, and discoverable through following links. That's the good way forwards and why to focus work on WMS-Next, WCS JSON bindings, and other modular extensions to OGC services.

= Issues with the document =

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

This critique is incomplete because it quickly falls into a full editorial review of the text, something which takes a lot of time and effort.

[[Geoservices_REST_API_critique]]

==A Quick Critique of the proposed standard document==

===The name===

The document currently uses a name that is confusing in all discussions on the matter, both internally at the OGC and externally.

(Postnote 9 May 2013: the Standards Working Group proposing the document agreed to accept proposals for new names; if they can find a good alternative, they may adopt it.)

===The design===

The document does not show an overall, coherent design to the service suite. This is mostly because the design reflects a suite that [initially] evolved piecemeal at ESRI rather than one designed from the start to meet the needs of a broad swath of users. This is also due because the experts at the OGC did not contribute to an improved design for a multitude of reasons.

The design of the service which does exist is focused on yesteryear. As an apology for the existing design, section~6.2.2 of part 1, Core says that the only HTTP verbs used are GET and PUT because "the API was originally developed several years ago" but that's okay because it enables support for "Microsoft Silverlight" and "Adobe Flex" two standards which are dying rapidly. In 2013, a new standard ought to be focused on the next 10 years not the past ten.

===The writing===

The document is poorly written.

====The document is poorly introduced====

The document should start with a discussion of the overall design of the suite of services and what each individual service provides within that suite. This would make it easy for a user to understand the focus of the suite. (The note between requirements~3 and requirement~4, stating that the spec makes no requirements on clients, is really part of the scope of the document and should be front and center.)

The document instead starts with a whole section on REST.

: 1. Scope
: The GeoServices REST API provides a standard way for web clients to communicate with geographic information system (GIS) servers based on Representational State Transfer (REST) principles.

The scope claims that the document identifies resources and a way to use "structured URLs" to exchange those resources between clients and services. If that were true, I would expect
: (1) a list of resources at least as an example, and
: (2) an example of the structure and structuring principles of the URLs.

Section~6 stats this process. Section~6.1 introduces the concept of a root URL for each service and mixes in that that root URL is also a catalog and that the hierarchy offers resources. This all happens in a single, overly compact paragraph. This section needs an editorial rewrite for clarity separating
: (1) the end point,
: (2) the catalog,
: (3) the URL hierarchy,
: (4) the resources, and
: (5) interaction of clients with the URLs through the exchange (get/post) of the resources to the different URLs.

Unfortunately, section~6 then decays into a meandering discussion of REST which mentions the buzzword a lot but does not discuss the aspects of REST design that have been met by the suite and those that have not. If REST is a form of design which offers certain benefits, OGC standards should be discussing the benefits achieved not the buzz word. To what extent are the resources cachable and how do clients and servers agree on that? To what extent are the endpoints and actions on those endpoints discoverable, and how? Those are the issues of RESTful design.

Section~6.3 discusses Resources but immediately then states:

: Each resource has a unique URL. Resources MAY support parameters.

which is a discussion of the URL hierarchy. (And 'Resources' do not 'support parameters'! Services may 'handle requests containing parameters' if that is what is meant.) Then the standard introduces a new idea 'Controller Resources' which are able to 'edit' and 'query'!? A web search does not reveal any formal discussion of 'Controller Resource' so this new type of resource probably deserves some kind of formal introduction.

Section~6.3.3 is not really about resources but the fact that the URL hierarchy is not discoverable from the Resources themselves.

Section~6.3.4 does give a list of resources, but since 'image' is not part of it but will be used by the Service for Map Images, I surmise that the list is of the things 'we have designed a JSON representation for' rather than a list of 'the resources identified and exchanged in the service suite' which is what I expect in an introductory design.

This introduction therefore needs a substantial editorial rewrite to be effective in its goal of explaining what the suite of standards actually does.

This criticism is not limited to the core document.

The Service for Maps document also starts without setting out the five core elements (end pt, catalog?, URL hierarchy, resources, and interactions).

Section~6 of the Service for Maps part, in the middle of the second paragraph, introduces a new concept, with capitalized letters:

: The Map Service Root resource includes a tables property ...

without giving us any clue what this is. It "provides basic information" (perhaps it is a data structure?) but it also "supports several operations" (maybe it's a magical 'Controller Resource'). To me, this just reads as 'the authors of the spec are confused and imprecise in their written language'.

Then, in the figure of 'Resources,' there is actually a resource called 'All layers and tables'. Sorry, but this reader needs some real help to understand what that resource might be.

==== The document requirements are poor ====

The very first requirement, Requirement~1 of the Core document, states:

: Req 1 If a request uses the HTTP GET method, the processing of the request by the service SHALL be safe and idempotent as specified by RFC 2616, 9.1.

This is a *ridiculous* requirement, completely untestable, and explicitly what the Mod Spec should be preventing with its attempt to require all injunctive language to be accompanied by formal tests. The formal test indeed shows that the requirement is untestable.

: Inspect the documentation of the implementation to identify, if requests specified in the GeoServices REST API standard that support the HTTP GET method, are all safe and idempotent, i.e. free of side- effects, as specified in HTTP (RFC 2616, section 9.1). Alternatively, ask the developer of the the service.

: Note that it is not possible to run automated tests against a service to verify conformance with the requirement (and IETF provides no test for conformance with HTTP either). In the absence of such tests, a statement of the developers of the service is sufficient indication that the requirement was addressed.

So essentially this requirement is met if the developers say 'yeah, we thought about it.' In other words, requirement 1 of the whole shebang is a recommendation. Contrast this with requirement 2 which has a nice test defined for it and is a good, solid requirement.

Again, broadening the critique to the Services for Maps, its first requirement states:

: Req 1 The Map Service Root resource SHALL accept requests that conform to the URI template in Table and use any HTTP method identified in the same table.

but the test is then completely irrelevant. At the protocol level, all web services 'shall accept' request messages, so we are not discussing that. A functional test for this 'shall accept' is to construct all valid requests and see that the service never returns an exception to those requests. Even worse, the first test is a catch all 'please test the service here' test. This is *not* a well written specification of the tests for the injunctions of the Service for Maps.

The requirements need a complete, systematic review to see that they work, they are testable, and have good tests.

==== The document has numerous other issues which need resolution ====

* There is no discussion of the overlap of the f= parameter and of the HTTP format header. What happens if they conflict?
* The lack of full integration of the four core HTTP verbs, notably DELETE and PUT, exists merely for backwards compatibility not for forwards progress.
* Requirement~3 blocks forwards progress and experimentation with no explanation as to its importance.
* This goes on and on. This is the work for an EDITOR. I am not interested in doing that work.

= Further Concerns =
--- DRAFT ____

''Please add concerns as bullet points below. Try to be concise. 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 ==

* 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.
* 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.
* 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 ==

# 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 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.

= References =
* 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
* Adrian Custer's eloquent, unbiased, concise summary of the technical issues: 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-10T16:29:07Z

Wiki-Acuster: /* Issues with the document */

This wiki page aims to collate community concerns related to the proposed acceptance of the "Geoservices REST API" becoming an OGC standard. It is being collaboratively edited, targeting completion before the end of May 2013.

= 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, which 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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[User:Hfpmartins | Hugo Martins]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], WebGIS Developer, OSGeo-Portugal Member
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member

= Summary =

The document titled "GeoServices REST API" is currently, in May 2013, being considered as a standard of the Open Geospatial Consortium (OGC). 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 JSON format.

The adoption of the document is contentious for a wide variety of reasons including:

* the process through which it was developed,
* the language of 'REST' and 'API' used by the document,
* the names of the standard and of the services is confusing
* the duplication of these new services with other services standardized by the OGC such as WMS, WFS, WCS, and WPS and with work, by those services, of adopting RESTful designs including URL hierarchies and JSON exchange formats,
* the specific format of JSON messages used, and
* the dominance of the vendor of the single complete implementation in the marketplace.

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 of 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 is a feel that adoption of the standard will likely result in a combination of the following:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

These issues have been answered by the authors of the document who state:

* 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, may be 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 of some of these services.

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

= Positions on the vote =

The discussion raises a number of issues even beyond those mentioned above. This makes difficult any rational decision by the voting members of the OGC Technical Committee, who will determine adoption or rejection of the vote.

The following is the analysis of positions on the vote, originally from a single person on his own point of view and therefore reaching a conclusion appropriate in particular to him. Obviously the signatories of the letter at the start of this page have reached different conclusions.

; The pros:

:* The OGC should be in the business of developing good standards, not of choosing which standards should be implemented.
:* The proposers of the document want to make a standard and have followed all the rules of the consortium. 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 an author of standards at the OGC, 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 is, de-facto, in the position of recommending the 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.
:* Adopting a standard implies a desire to maintain the standard, but the desire to support this approach by the OGC membership is limited. The lack of collaboration on this version 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 implemetation.
:* 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 rewrite. (see at end)

; The 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. (On that, perhaps they should be allowed to make their own mistakes.) The path forwards towards harmonizing the services is unclear. There is little good will towards the standard on behalf of the membership. 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 a third way?

Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to build this thing that we want, an integrated suite of simple services built using simple, well defined resources, accessible and usable using the core HTTP verbs, and discoverable through following links. That's the good way forwards and why to focus work on WMS-Next, WCS JSON bindings, and other modular extensions to OGC services.

= Issues with the document =

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

This critique is incomplete because it quickly falls into a full editorial review of the text, something which takes a lot of time and effort.

[Geoservices_REST_API_critique]

==A Quick Critique of the proposed standard document==

===The name===

The document currently uses a name that is confusing in all discussions on the matter, both internally at the OGC and externally.

(Postnote 9 May 2013: the Standards Working Group proposing the document agreed to accept proposals for new names; if they can find a good alternative, they may adopt it.)

===The design===

The document does not show an overall, coherent design to the service suite. This is mostly because the design reflects a suite that [initially] evolved piecemeal at ESRI rather than one designed from the start to meet the needs of a broad swath of users. This is also due because the experts at the OGC did not contribute to an improved design for a multitude of reasons.

The design of the service which does exist is focused on yesteryear. As an apology for the existing design, section~6.2.2 of part 1, Core says that the only HTTP verbs used are GET and PUT because "the API was originally developed several years ago" but that's okay because it enables support for "Microsoft Silverlight" and "Adobe Flex" two standards which are dying rapidly. In 2013, a new standard ought to be focused on the next 10 years not the past ten.

===The writing===

The document is poorly written.

====The document is poorly introduced====

The document should start with a discussion of the overall design of the suite of services and what each individual service provides within that suite. This would make it easy for a user to understand the focus of the suite. (The note between requirements~3 and requirement~4, stating that the spec makes no requirements on clients, is really part of the scope of the document and should be front and center.)

The document instead starts with a whole section on REST.

: 1. Scope
: The GeoServices REST API provides a standard way for web clients to communicate with geographic information system (GIS) servers based on Representational State Transfer (REST) principles.

The scope claims that the document identifies resources and a way to use "structured URLs" to exchange those resources between clients and services. If that were true, I would expect
: (1) a list of resources at least as an example, and
: (2) an example of the structure and structuring principles of the URLs.

Section~6 stats this process. Section~6.1 introduces the concept of a root URL for each service and mixes in that that root URL is also a catalog and that the hierarchy offers resources. This all happens in a single, overly compact paragraph. This section needs an editorial rewrite for clarity separating
: (1) the end point,
: (2) the catalog,
: (3) the URL hierarchy,
: (4) the resources, and
: (5) interaction of clients with the URLs through the exchange (get/post) of the resources to the different URLs.

Unfortunately, section~6 then decays into a meandering discussion of REST which mentions the buzzword a lot but does not discuss the aspects of REST design that have been met by the suite and those that have not. If REST is a form of design which offers certain benefits, OGC standards should be discussing the benefits achieved not the buzz word. To what extent are the resources cachable and how do clients and servers agree on that? To what extent are the endpoints and actions on those endpoints discoverable, and how? Those are the issues of RESTful design.

Section~6.3 discusses Resources but immediately then states:

: Each resource has a unique URL. Resources MAY support parameters.

which is a discussion of the URL hierarchy. (And 'Resources' do not 'support parameters'! Services may 'handle requests containing parameters' if that is what is meant.) Then the standard introduces a new idea 'Controller Resources' which are able to 'edit' and 'query'!? A web search does not reveal any formal discussion of 'Controller Resource' so this new type of resource probably deserves some kind of formal introduction.

Section~6.3.3 is not really about resources but the fact that the URL hierarchy is not discoverable from the Resources themselves.

Section~6.3.4 does give a list of resources, but since 'image' is not part of it but will be used by the Service for Map Images, I surmise that the list is of the things 'we have designed a JSON representation for' rather than a list of 'the resources identified and exchanged in the service suite' which is what I expect in an introductory design.

This introduction therefore needs a substantial editorial rewrite to be effective in its goal of explaining what the suite of standards actually does.

This criticism is not limited to the core document.

The Service for Maps document also starts without setting out the five core elements (end pt, catalog?, URL hierarchy, resources, and interactions).

Section~6 of the Service for Maps part, in the middle of the second paragraph, introduces a new concept, with capitalized letters:

: The Map Service Root resource includes a tables property ...

without giving us any clue what this is. It "provides basic information" (perhaps it is a data structure?) but it also "supports several operations" (maybe it's a magical 'Controller Resource'). To me, this just reads as 'the authors of the spec are confused and imprecise in their written language'.

Then, in the figure of 'Resources,' there is actually a resource called 'All layers and tables'. Sorry, but this reader needs some real help to understand what that resource might be.

==== The document requirements are poor ====

The very first requirement, Requirement~1 of the Core document, states:

: Req 1 If a request uses the HTTP GET method, the processing of the request by the service SHALL be safe and idempotent as specified by RFC 2616, 9.1.

This is a *ridiculous* requirement, completely untestable, and explicitly what the Mod Spec should be preventing with its attempt to require all injunctive language to be accompanied by formal tests. The formal test indeed shows that the requirement is untestable.

: Inspect the documentation of the implementation to identify, if requests specified in the GeoServices REST API standard that support the HTTP GET method, are all safe and idempotent, i.e. free of side- effects, as specified in HTTP (RFC 2616, section 9.1). Alternatively, ask the developer of the the service.

: Note that it is not possible to run automated tests against a service to verify conformance with the requirement (and IETF provides no test for conformance with HTTP either). In the absence of such tests, a statement of the developers of the service is sufficient indication that the requirement was addressed.

So essentially this requirement is met if the developers say 'yeah, we thought about it.' In other words, requirement 1 of the whole shebang is a recommendation. Contrast this with requirement 2 which has a nice test defined for it and is a good, solid requirement.

Again, broadening the critique to the Services for Maps, its first requirement states:

: Req 1 The Map Service Root resource SHALL accept requests that conform to the URI template in Table and use any HTTP method identified in the same table.

but the test is then completely irrelevant. At the protocol level, all web services 'shall accept' request messages, so we are not discussing that. A functional test for this 'shall accept' is to construct all valid requests and see that the service never returns an exception to those requests. Even worse, the first test is a catch all 'please test the service here' test. This is *not* a well written specification of the tests for the injunctions of the Service for Maps.

The requirements need a complete, systematic review to see that they work, they are testable, and have good tests.

==== The document has numerous other issues which need resolution ====

* There is no discussion of the overlap of the f= parameter and of the HTTP format header. What happens if they conflict?
* The lack of full integration of the four core HTTP verbs, notably DELETE and PUT, exists merely for backwards compatibility not for forwards progress.
* Requirement~3 blocks forwards progress and experimentation with no explanation as to its importance.
* This goes on and on. This is the work for an EDITOR. I am not interested in doing that work.

= Further Concerns =
--- DRAFT ____

''Please add concerns as bullet points below. Try to be concise. 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 ==

* 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.
* 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.
* 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 ==

# 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 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.

= References =
* 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
* Adrian Custer's eloquent, unbiased, concise summary of the technical issues: 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-10T16:27:28Z

Wiki-Acuster: /* References */

This wiki page aims to collate community concerns related to the proposed acceptance of the "Geoservices REST API" becoming an OGC standard. It is being collaboratively edited, targeting completion before the end of May 2013.

= 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, which 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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[User:Hfpmartins | Hugo Martins]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], WebGIS Developer, OSGeo-Portugal Member
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member

= Summary =

The document titled "GeoServices REST API" is currently, in May 2013, being considered as a standard of the Open Geospatial Consortium (OGC). 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 JSON format.

The adoption of the document is contentious for a wide variety of reasons including:

* the process through which it was developed,
* the language of 'REST' and 'API' used by the document,
* the names of the standard and of the services is confusing
* the duplication of these new services with other services standardized by the OGC such as WMS, WFS, WCS, and WPS and with work, by those services, of adopting RESTful designs including URL hierarchies and JSON exchange formats,
* the specific format of JSON messages used, and
* the dominance of the vendor of the single complete implementation in the marketplace.

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 of 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 is a feel that adoption of the standard will likely result in a combination of the following:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

These issues have been answered by the authors of the document who state:

* 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, may be 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 of some of these services.

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

= Positions on the vote =

The discussion raises a number of issues even beyond those mentioned above. This makes difficult any rational decision by the voting members of the OGC Technical Committee, who will determine adoption or rejection of the vote.

The following is the analysis of positions on the vote, originally from a single person on his own point of view and therefore reaching a conclusion appropriate in particular to him. Obviously the signatories of the letter at the start of this page have reached different conclusions.

; The pros:

:* The OGC should be in the business of developing good standards, not of choosing which standards should be implemented.
:* The proposers of the document want to make a standard and have followed all the rules of the consortium. 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 an author of standards at the OGC, 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 is, de-facto, in the position of recommending the 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.
:* Adopting a standard implies a desire to maintain the standard, but the desire to support this approach by the OGC membership is limited. The lack of collaboration on this version 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 implemetation.
:* 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 rewrite. (see at end)

; The 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. (On that, perhaps they should be allowed to make their own mistakes.) The path forwards towards harmonizing the services is unclear. There is little good will towards the standard on behalf of the membership. 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 a third way?

Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to build this thing that we want, an integrated suite of simple services built using simple, well defined resources, accessible and usable using the core HTTP verbs, and discoverable through following links. That's the good way forwards and why to focus work on WMS-Next, WCS JSON bindings, and other modular extensions to OGC services.

= Issues with the document =

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

This critique is incomplete because it quickly falls into a full editorial review of the text, something which takes a lot of time and effort.

==A Quick Critique of the proposed standard document==

===The name===

The document currently uses a name that is confusing in all discussions on the matter, both internally at the OGC and externally.

(Postnote 9 May 2013: the Standards Working Group proposing the document agreed to accept proposals for new names; if they can find a good alternative, they may adopt it.)

===The design===

The document does not show an overall, coherent design to the service suite. This is mostly because the design reflects a suite that [initially] evolved piecemeal at ESRI rather than one designed from the start to meet the needs of a broad swath of users. This is also due because the experts at the OGC did not contribute to an improved design for a multitude of reasons.

The design of the service which does exist is focused on yesteryear. As an apology for the existing design, section~6.2.2 of part 1, Core says that the only HTTP verbs used are GET and PUT because "the API was originally developed several years ago" but that's okay because it enables support for "Microsoft Silverlight" and "Adobe Flex" two standards which are dying rapidly. In 2013, a new standard ought to be focused on the next 10 years not the past ten.

===The writing===

The document is poorly written.

====The document is poorly introduced====

The document should start with a discussion of the overall design of the suite of services and what each individual service provides within that suite. This would make it easy for a user to understand the focus of the suite. (The note between requirements~3 and requirement~4, stating that the spec makes no requirements on clients, is really part of the scope of the document and should be front and center.)

The document instead starts with a whole section on REST.

: 1. Scope
: The GeoServices REST API provides a standard way for web clients to communicate with geographic information system (GIS) servers based on Representational State Transfer (REST) principles.

The scope claims that the document identifies resources and a way to use "structured URLs" to exchange those resources between clients and services. If that were true, I would expect
: (1) a list of resources at least as an example, and
: (2) an example of the structure and structuring principles of the URLs.

Section~6 stats this process. Section~6.1 introduces the concept of a root URL for each service and mixes in that that root URL is also a catalog and that the hierarchy offers resources. This all happens in a single, overly compact paragraph. This section needs an editorial rewrite for clarity separating
: (1) the end point,
: (2) the catalog,
: (3) the URL hierarchy,
: (4) the resources, and
: (5) interaction of clients with the URLs through the exchange (get/post) of the resources to the different URLs.

Unfortunately, section~6 then decays into a meandering discussion of REST which mentions the buzzword a lot but does not discuss the aspects of REST design that have been met by the suite and those that have not. If REST is a form of design which offers certain benefits, OGC standards should be discussing the benefits achieved not the buzz word. To what extent are the resources cachable and how do clients and servers agree on that? To what extent are the endpoints and actions on those endpoints discoverable, and how? Those are the issues of RESTful design.

Section~6.3 discusses Resources but immediately then states:

: Each resource has a unique URL. Resources MAY support parameters.

which is a discussion of the URL hierarchy. (And 'Resources' do not 'support parameters'! Services may 'handle requests containing parameters' if that is what is meant.) Then the standard introduces a new idea 'Controller Resources' which are able to 'edit' and 'query'!? A web search does not reveal any formal discussion of 'Controller Resource' so this new type of resource probably deserves some kind of formal introduction.

Section~6.3.3 is not really about resources but the fact that the URL hierarchy is not discoverable from the Resources themselves.

Section~6.3.4 does give a list of resources, but since 'image' is not part of it but will be used by the Service for Map Images, I surmise that the list is of the things 'we have designed a JSON representation for' rather than a list of 'the resources identified and exchanged in the service suite' which is what I expect in an introductory design.

This introduction therefore needs a substantial editorial rewrite to be effective in its goal of explaining what the suite of standards actually does.

This criticism is not limited to the core document.

The Service for Maps document also starts without setting out the five core elements (end pt, catalog?, URL hierarchy, resources, and interactions).

Section~6 of the Service for Maps part, in the middle of the second paragraph, introduces a new concept, with capitalized letters:

: The Map Service Root resource includes a tables property ...

without giving us any clue what this is. It "provides basic information" (perhaps it is a data structure?) but it also "supports several operations" (maybe it's a magical 'Controller Resource'). To me, this just reads as 'the authors of the spec are confused and imprecise in their written language'.

Then, in the figure of 'Resources,' there is actually a resource called 'All layers and tables'. Sorry, but this reader needs some real help to understand what that resource might be.

==== The document requirements are poor ====

The very first requirement, Requirement~1 of the Core document, states:

: Req 1 If a request uses the HTTP GET method, the processing of the request by the service SHALL be safe and idempotent as specified by RFC 2616, 9.1.

This is a *ridiculous* requirement, completely untestable, and explicitly what the Mod Spec should be preventing with its attempt to require all injunctive language to be accompanied by formal tests. The formal test indeed shows that the requirement is untestable.

: Inspect the documentation of the implementation to identify, if requests specified in the GeoServices REST API standard that support the HTTP GET method, are all safe and idempotent, i.e. free of side- effects, as specified in HTTP (RFC 2616, section 9.1). Alternatively, ask the developer of the the service.

: Note that it is not possible to run automated tests against a service to verify conformance with the requirement (and IETF provides no test for conformance with HTTP either). In the absence of such tests, a statement of the developers of the service is sufficient indication that the requirement was addressed.

So essentially this requirement is met if the developers say 'yeah, we thought about it.' In other words, requirement 1 of the whole shebang is a recommendation. Contrast this with requirement 2 which has a nice test defined for it and is a good, solid requirement.

Again, broadening the critique to the Services for Maps, its first requirement states:

: Req 1 The Map Service Root resource SHALL accept requests that conform to the URI template in Table and use any HTTP method identified in the same table.

but the test is then completely irrelevant. At the protocol level, all web services 'shall accept' request messages, so we are not discussing that. A functional test for this 'shall accept' is to construct all valid requests and see that the service never returns an exception to those requests. Even worse, the first test is a catch all 'please test the service here' test. This is *not* a well written specification of the tests for the injunctions of the Service for Maps.

The requirements need a complete, systematic review to see that they work, they are testable, and have good tests.

==== The document has numerous other issues which need resolution ====

* There is no discussion of the overlap of the f= parameter and of the HTTP format header. What happens if they conflict?
* The lack of full integration of the four core HTTP verbs, notably DELETE and PUT, exists merely for backwards compatibility not for forwards progress.
* Requirement~3 blocks forwards progress and experimentation with no explanation as to its importance.
* This goes on and on. This is the work for an EDITOR. I am not interested in doing that work.

= Further Concerns =
--- DRAFT ____

''Please add concerns as bullet points below. Try to be concise. 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 ==

* 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.
* 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.
* 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 ==

# 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 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.

= References =
* 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
* Adrian Custer's eloquent, unbiased, concise summary of the technical issues: 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-10T16:26:59Z

Wiki-Acuster: /* Methodological Concerns */

This wiki page aims to collate community concerns related to the proposed acceptance of the "Geoservices REST API" becoming an OGC standard. It is being collaboratively edited, targeting completion before the end of May 2013.

= 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, which 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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[User:Hfpmartins | Hugo Martins]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], WebGIS Developer, OSGeo-Portugal Member
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member

= Summary =

The document titled "GeoServices REST API" is currently, in May 2013, being considered as a standard of the Open Geospatial Consortium (OGC). 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 JSON format.

The adoption of the document is contentious for a wide variety of reasons including:

* the process through which it was developed,
* the language of 'REST' and 'API' used by the document,
* the names of the standard and of the services is confusing
* the duplication of these new services with other services standardized by the OGC such as WMS, WFS, WCS, and WPS and with work, by those services, of adopting RESTful designs including URL hierarchies and JSON exchange formats,
* the specific format of JSON messages used, and
* the dominance of the vendor of the single complete implementation in the marketplace.

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 of 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 is a feel that adoption of the standard will likely result in a combination of the following:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

These issues have been answered by the authors of the document who state:

* 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, may be 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 of some of these services.

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

= Positions on the vote =

The discussion raises a number of issues even beyond those mentioned above. This makes difficult any rational decision by the voting members of the OGC Technical Committee, who will determine adoption or rejection of the vote.

The following is the analysis of positions on the vote, originally from a single person on his own point of view and therefore reaching a conclusion appropriate in particular to him. Obviously the signatories of the letter at the start of this page have reached different conclusions.

; The pros:

:* The OGC should be in the business of developing good standards, not of choosing which standards should be implemented.
:* The proposers of the document want to make a standard and have followed all the rules of the consortium. 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 an author of standards at the OGC, 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 is, de-facto, in the position of recommending the 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.
:* Adopting a standard implies a desire to maintain the standard, but the desire to support this approach by the OGC membership is limited. The lack of collaboration on this version 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 implemetation.
:* 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 rewrite. (see at end)

; The 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. (On that, perhaps they should be allowed to make their own mistakes.) The path forwards towards harmonizing the services is unclear. There is little good will towards the standard on behalf of the membership. 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 a third way?

Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to build this thing that we want, an integrated suite of simple services built using simple, well defined resources, accessible and usable using the core HTTP verbs, and discoverable through following links. That's the good way forwards and why to focus work on WMS-Next, WCS JSON bindings, and other modular extensions to OGC services.

= Issues with the document =

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

This critique is incomplete because it quickly falls into a full editorial review of the text, something which takes a lot of time and effort.

==A Quick Critique of the proposed standard document==

===The name===

The document currently uses a name that is confusing in all discussions on the matter, both internally at the OGC and externally.

(Postnote 9 May 2013: the Standards Working Group proposing the document agreed to accept proposals for new names; if they can find a good alternative, they may adopt it.)

===The design===

The document does not show an overall, coherent design to the service suite. This is mostly because the design reflects a suite that [initially] evolved piecemeal at ESRI rather than one designed from the start to meet the needs of a broad swath of users. This is also due because the experts at the OGC did not contribute to an improved design for a multitude of reasons.

The design of the service which does exist is focused on yesteryear. As an apology for the existing design, section~6.2.2 of part 1, Core says that the only HTTP verbs used are GET and PUT because "the API was originally developed several years ago" but that's okay because it enables support for "Microsoft Silverlight" and "Adobe Flex" two standards which are dying rapidly. In 2013, a new standard ought to be focused on the next 10 years not the past ten.

===The writing===

The document is poorly written.

====The document is poorly introduced====

The document should start with a discussion of the overall design of the suite of services and what each individual service provides within that suite. This would make it easy for a user to understand the focus of the suite. (The note between requirements~3 and requirement~4, stating that the spec makes no requirements on clients, is really part of the scope of the document and should be front and center.)

The document instead starts with a whole section on REST.

: 1. Scope
: The GeoServices REST API provides a standard way for web clients to communicate with geographic information system (GIS) servers based on Representational State Transfer (REST) principles.

The scope claims that the document identifies resources and a way to use "structured URLs" to exchange those resources between clients and services. If that were true, I would expect
: (1) a list of resources at least as an example, and
: (2) an example of the structure and structuring principles of the URLs.

Section~6 stats this process. Section~6.1 introduces the concept of a root URL for each service and mixes in that that root URL is also a catalog and that the hierarchy offers resources. This all happens in a single, overly compact paragraph. This section needs an editorial rewrite for clarity separating
: (1) the end point,
: (2) the catalog,
: (3) the URL hierarchy,
: (4) the resources, and
: (5) interaction of clients with the URLs through the exchange (get/post) of the resources to the different URLs.

Unfortunately, section~6 then decays into a meandering discussion of REST which mentions the buzzword a lot but does not discuss the aspects of REST design that have been met by the suite and those that have not. If REST is a form of design which offers certain benefits, OGC standards should be discussing the benefits achieved not the buzz word. To what extent are the resources cachable and how do clients and servers agree on that? To what extent are the endpoints and actions on those endpoints discoverable, and how? Those are the issues of RESTful design.

Section~6.3 discusses Resources but immediately then states:

: Each resource has a unique URL. Resources MAY support parameters.

which is a discussion of the URL hierarchy. (And 'Resources' do not 'support parameters'! Services may 'handle requests containing parameters' if that is what is meant.) Then the standard introduces a new idea 'Controller Resources' which are able to 'edit' and 'query'!? A web search does not reveal any formal discussion of 'Controller Resource' so this new type of resource probably deserves some kind of formal introduction.

Section~6.3.3 is not really about resources but the fact that the URL hierarchy is not discoverable from the Resources themselves.

Section~6.3.4 does give a list of resources, but since 'image' is not part of it but will be used by the Service for Map Images, I surmise that the list is of the things 'we have designed a JSON representation for' rather than a list of 'the resources identified and exchanged in the service suite' which is what I expect in an introductory design.

This introduction therefore needs a substantial editorial rewrite to be effective in its goal of explaining what the suite of standards actually does.

This criticism is not limited to the core document.

The Service for Maps document also starts without setting out the five core elements (end pt, catalog?, URL hierarchy, resources, and interactions).

Section~6 of the Service for Maps part, in the middle of the second paragraph, introduces a new concept, with capitalized letters:

: The Map Service Root resource includes a tables property ...

without giving us any clue what this is. It "provides basic information" (perhaps it is a data structure?) but it also "supports several operations" (maybe it's a magical 'Controller Resource'). To me, this just reads as 'the authors of the spec are confused and imprecise in their written language'.

Then, in the figure of 'Resources,' there is actually a resource called 'All layers and tables'. Sorry, but this reader needs some real help to understand what that resource might be.

==== The document requirements are poor ====

The very first requirement, Requirement~1 of the Core document, states:

: Req 1 If a request uses the HTTP GET method, the processing of the request by the service SHALL be safe and idempotent as specified by RFC 2616, 9.1.

This is a *ridiculous* requirement, completely untestable, and explicitly what the Mod Spec should be preventing with its attempt to require all injunctive language to be accompanied by formal tests. The formal test indeed shows that the requirement is untestable.

: Inspect the documentation of the implementation to identify, if requests specified in the GeoServices REST API standard that support the HTTP GET method, are all safe and idempotent, i.e. free of side- effects, as specified in HTTP (RFC 2616, section 9.1). Alternatively, ask the developer of the the service.

: Note that it is not possible to run automated tests against a service to verify conformance with the requirement (and IETF provides no test for conformance with HTTP either). In the absence of such tests, a statement of the developers of the service is sufficient indication that the requirement was addressed.

So essentially this requirement is met if the developers say 'yeah, we thought about it.' In other words, requirement 1 of the whole shebang is a recommendation. Contrast this with requirement 2 which has a nice test defined for it and is a good, solid requirement.

Again, broadening the critique to the Services for Maps, its first requirement states:

: Req 1 The Map Service Root resource SHALL accept requests that conform to the URI template in Table and use any HTTP method identified in the same table.

but the test is then completely irrelevant. At the protocol level, all web services 'shall accept' request messages, so we are not discussing that. A functional test for this 'shall accept' is to construct all valid requests and see that the service never returns an exception to those requests. Even worse, the first test is a catch all 'please test the service here' test. This is *not* a well written specification of the tests for the injunctions of the Service for Maps.

The requirements need a complete, systematic review to see that they work, they are testable, and have good tests.

==== The document has numerous other issues which need resolution ====

* There is no discussion of the overlap of the f= parameter and of the HTTP format header. What happens if they conflict?
* The lack of full integration of the four core HTTP verbs, notably DELETE and PUT, exists merely for backwards compatibility not for forwards progress.
* Requirement~3 blocks forwards progress and experimentation with no explanation as to its importance.
* This goes on and on. This is the work for an EDITOR. I am not interested in doing that work.

= Further Concerns =
--- DRAFT ____

''Please add concerns as bullet points below. Try to be concise. 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 ==

* 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.
* 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.
* 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 ==

# 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 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.

= References =
* 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
** Adrian Custer's eloquent, unbiased, concise summary of the technical issues: 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-10T16:21:59Z

Wiki-Acuster: /* Analysis of the Controversy */

This wiki page aims to collate community concerns related to the proposed acceptance of the "Geoservices REST API" becoming an OGC standard. It is being collaboratively edited, targeting completion before the end of May 2013.

= 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, which 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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[User:Hfpmartins | Hugo Martins]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], WebGIS Developer, OSGeo-Portugal Member
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member

= Summary =

The document titled "GeoServices REST API" is currently, in May 2013, being considered as a standard of the Open Geospatial Consortium (OGC). 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 JSON format.

The adoption of the document is contentious for a wide variety of reasons including:

* the process through which it was developed,
* the language of 'REST' and 'API' used by the document,
* the names of the standard and of the services is confusing
* the duplication of these new services with other services standardized by the OGC such as WMS, WFS, WCS, and WPS and with work, by those services, of adopting RESTful designs including URL hierarchies and JSON exchange formats,
* the specific format of JSON messages used, and
* the dominance of the vendor of the single complete implementation in the marketplace.

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 of 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 is a feel that adoption of the standard will likely result in a combination of the following:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

These issues have been answered by the authors of the document who state:

* 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, may be 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 of some of these services.

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

= Positions on the vote =

The discussion raises a number of issues even beyond those mentioned above. This makes difficult any rational decision by the voting members of the OGC Technical Committee, who will determine adoption or rejection of the vote.

The following is the analysis of positions on the vote, originally from a single person on his own point of view and therefore reaching a conclusion appropriate in particular to him. Obviously the signatories of the letter at the start of this page have reached different conclusions.

; The pros:

:* The OGC should be in the business of developing good standards, not of choosing which standards should be implemented.
:* The proposers of the document want to make a standard and have followed all the rules of the consortium. 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 an author of standards at the OGC, 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 is, de-facto, in the position of recommending the 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.
:* Adopting a standard implies a desire to maintain the standard, but the desire to support this approach by the OGC membership is limited. The lack of collaboration on this version 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 implemetation.
:* 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 rewrite. (see at end)

; The 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. (On that, perhaps they should be allowed to make their own mistakes.) The path forwards towards harmonizing the services is unclear. There is little good will towards the standard on behalf of the membership. 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 a third way?

Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to build this thing that we want, an integrated suite of simple services built using simple, well defined resources, accessible and usable using the core HTTP verbs, and discoverable through following links. That's the good way forwards and why to focus work on WMS-Next, WCS JSON bindings, and other modular extensions to OGC services.

= Issues with the document =

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

This critique is incomplete because it quickly falls into a full editorial review of the text, something which takes a lot of time and effort.

==A Quick Critique of the proposed standard document==

===The name===

The document currently uses a name that is confusing in all discussions on the matter, both internally at the OGC and externally.

(Postnote 9 May 2013: the Standards Working Group proposing the document agreed to accept proposals for new names; if they can find a good alternative, they may adopt it.)

===The design===

The document does not show an overall, coherent design to the service suite. This is mostly because the design reflects a suite that [initially] evolved piecemeal at ESRI rather than one designed from the start to meet the needs of a broad swath of users. This is also due because the experts at the OGC did not contribute to an improved design for a multitude of reasons.

The design of the service which does exist is focused on yesteryear. As an apology for the existing design, section~6.2.2 of part 1, Core says that the only HTTP verbs used are GET and PUT because "the API was originally developed several years ago" but that's okay because it enables support for "Microsoft Silverlight" and "Adobe Flex" two standards which are dying rapidly. In 2013, a new standard ought to be focused on the next 10 years not the past ten.

===The writing===

The document is poorly written.

====The document is poorly introduced====

The document should start with a discussion of the overall design of the suite of services and what each individual service provides within that suite. This would make it easy for a user to understand the focus of the suite. (The note between requirements~3 and requirement~4, stating that the spec makes no requirements on clients, is really part of the scope of the document and should be front and center.)

The document instead starts with a whole section on REST.

: 1. Scope
: The GeoServices REST API provides a standard way for web clients to communicate with geographic information system (GIS) servers based on Representational State Transfer (REST) principles.

The scope claims that the document identifies resources and a way to use "structured URLs" to exchange those resources between clients and services. If that were true, I would expect
: (1) a list of resources at least as an example, and
: (2) an example of the structure and structuring principles of the URLs.

Section~6 stats this process. Section~6.1 introduces the concept of a root URL for each service and mixes in that that root URL is also a catalog and that the hierarchy offers resources. This all happens in a single, overly compact paragraph. This section needs an editorial rewrite for clarity separating
: (1) the end point,
: (2) the catalog,
: (3) the URL hierarchy,
: (4) the resources, and
: (5) interaction of clients with the URLs through the exchange (get/post) of the resources to the different URLs.

Unfortunately, section~6 then decays into a meandering discussion of REST which mentions the buzzword a lot but does not discuss the aspects of REST design that have been met by the suite and those that have not. If REST is a form of design which offers certain benefits, OGC standards should be discussing the benefits achieved not the buzz word. To what extent are the resources cachable and how do clients and servers agree on that? To what extent are the endpoints and actions on those endpoints discoverable, and how? Those are the issues of RESTful design.

Section~6.3 discusses Resources but immediately then states:

: Each resource has a unique URL. Resources MAY support parameters.

which is a discussion of the URL hierarchy. (And 'Resources' do not 'support parameters'! Services may 'handle requests containing parameters' if that is what is meant.) Then the standard introduces a new idea 'Controller Resources' which are able to 'edit' and 'query'!? A web search does not reveal any formal discussion of 'Controller Resource' so this new type of resource probably deserves some kind of formal introduction.

Section~6.3.3 is not really about resources but the fact that the URL hierarchy is not discoverable from the Resources themselves.

Section~6.3.4 does give a list of resources, but since 'image' is not part of it but will be used by the Service for Map Images, I surmise that the list is of the things 'we have designed a JSON representation for' rather than a list of 'the resources identified and exchanged in the service suite' which is what I expect in an introductory design.

This introduction therefore needs a substantial editorial rewrite to be effective in its goal of explaining what the suite of standards actually does.

This criticism is not limited to the core document.

The Service for Maps document also starts without setting out the five core elements (end pt, catalog?, URL hierarchy, resources, and interactions).

Section~6 of the Service for Maps part, in the middle of the second paragraph, introduces a new concept, with capitalized letters:

: The Map Service Root resource includes a tables property ...

without giving us any clue what this is. It "provides basic information" (perhaps it is a data structure?) but it also "supports several operations" (maybe it's a magical 'Controller Resource'). To me, this just reads as 'the authors of the spec are confused and imprecise in their written language'.

Then, in the figure of 'Resources,' there is actually a resource called 'All layers and tables'. Sorry, but this reader needs some real help to understand what that resource might be.

==== The document requirements are poor ====

The very first requirement, Requirement~1 of the Core document, states:

: Req 1 If a request uses the HTTP GET method, the processing of the request by the service SHALL be safe and idempotent as specified by RFC 2616, 9.1.

This is a *ridiculous* requirement, completely untestable, and explicitly what the Mod Spec should be preventing with its attempt to require all injunctive language to be accompanied by formal tests. The formal test indeed shows that the requirement is untestable.

: Inspect the documentation of the implementation to identify, if requests specified in the GeoServices REST API standard that support the HTTP GET method, are all safe and idempotent, i.e. free of side- effects, as specified in HTTP (RFC 2616, section 9.1). Alternatively, ask the developer of the the service.

: Note that it is not possible to run automated tests against a service to verify conformance with the requirement (and IETF provides no test for conformance with HTTP either). In the absence of such tests, a statement of the developers of the service is sufficient indication that the requirement was addressed.

So essentially this requirement is met if the developers say 'yeah, we thought about it.' In other words, requirement 1 of the whole shebang is a recommendation. Contrast this with requirement 2 which has a nice test defined for it and is a good, solid requirement.

Again, broadening the critique to the Services for Maps, its first requirement states:

: Req 1 The Map Service Root resource SHALL accept requests that conform to the URI template in Table and use any HTTP method identified in the same table.

but the test is then completely irrelevant. At the protocol level, all web services 'shall accept' request messages, so we are not discussing that. A functional test for this 'shall accept' is to construct all valid requests and see that the service never returns an exception to those requests. Even worse, the first test is a catch all 'please test the service here' test. This is *not* a well written specification of the tests for the injunctions of the Service for Maps.

The requirements need a complete, systematic review to see that they work, they are testable, and have good tests.

==== The document has numerous other issues which need resolution ====

* There is no discussion of the overlap of the f= parameter and of the HTTP format header. What happens if they conflict?
* The lack of full integration of the four core HTTP verbs, notably DELETE and PUT, exists merely for backwards compatibility not for forwards progress.
* Requirement~3 blocks forwards progress and experimentation with no explanation as to its importance.
* This goes on and on. This is the work for an EDITOR. I am not interested in doing that work.

= Further Concerns =
--- DRAFT ____

''Please add concerns as bullet points below. Try to be concise. 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 ==

* 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.
* 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.
* 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 ==

* 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 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.

= References =
* 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
** Adrian Custer's eloquent, unbiased, concise summary of the technical issues: 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-10T16:17:46Z

Wiki-Acuster: /* Analysis */ Remove comments; Reformat issues; Split voting position analysis

This wiki page aims to collate community concerns related to the proposed acceptance of the "Geoservices REST API" becoming an OGC standard. It is being collaboratively edited, targeting completion before the end of May 2013.

= 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, which 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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[User:Hfpmartins | Hugo Martins]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], WebGIS Developer, OSGeo-Portugal Member
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member
# [[User:AndreMano | AndreMano]], Portugal, Natural History Society - GIS Department, OSGeo-Portugal Member

= Summary =

The document titled "GeoServices REST API" is currently, in May 2013, being considered as a standard of the Open Geospatial Consortium (OGC). 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 JSON format.

The adoption of the document is contentious for a wide variety of reasons including:

* the process through which it was developed,
* the language of 'REST' and 'API' used by the document,
* the names of the standard and of the services is confusing
* the duplication of these new services with other services standardized by the OGC such as WMS, WFS, WCS, and WPS and with work, by those services, of adopting RESTful designs including URL hierarchies and JSON exchange formats,
* the specific format of JSON messages used, and
* the dominance of the vendor of the single complete implementation in the marketplace.

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 of 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 is a feel that adoption of the standard will likely result in a combination of the following:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

These issues have been answered by the authors of the document who state:

* 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, may be 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 of some of these services.

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

= Analysis of the Controversy=

The discussion raises a number of issues even beyond those mentioned above. This makes difficult any rational decision by the voting members of the OGC Technical Committee, who will determine adoption or rejection of the vote.

The following is the analysis originally from a single person on his own point of view.

; The pros:
:* The OGC should be in the business of developing good standards, not of choosing which standards should be implemented.
:* The proposers of the document want to make a standard and have followed all the rules of the consortium. 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 an author of standards at the OGC, 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 is, de-facto, in the position of recommending the 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.
:* Adopting a standard implies a desire to maintain the standard, but the desire to support this approach by the OGC membership is limited. The lack of collaboration on this version 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 implemetation.
:* 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 rewrite. (see at end)

; The 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. (On that, perhaps they should be allowed to make their own mistakes.) The path forwards towards harmonizing the services is unclear. There is little good will towards the standard on behalf of the membership. 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 a third way?

Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to build this thing that we want, an integrated suite of simple services built using simple, well defined resources, accessible and usable using the core HTTP verbs, and discoverable through following links. That's the way forwards and why to work on WMS-Next, WCS JSON bindings, and other modular extensions to OGC services.

= Issues with the document =

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

This critique is incomplete because it quickly falls into a full editorial review of the text, something which takes a lot of time and effort.

==A Quick Critique of the proposed standard document==

===The name===

The document currently uses a name that is confusing in all discussions on the matter, both internally at the OGC and externally.

(Postnote 9 May 2013: the Standards Working Group proposing the document agreed to accept proposals for new names; if they can find a good alternative, they may adopt it.)

===The design===

The document does not show an overall, coherent design to the service suite. This is mostly because the design reflects a suite that [initially] evolved piecemeal at ESRI rather than one designed from the start to meet the needs of a broad swath of users. This is also due because the experts at the OGC did not contribute to an improved design for a multitude of reasons.

The design of the service which does exist is focused on yesteryear. As an apology for the existing design, section~6.2.2 of part 1, Core says that the only HTTP verbs used are GET and PUT because "the API was originally developed several years ago" but that's okay because it enables support for "Microsoft Silverlight" and "Adobe Flex" two standards which are dying rapidly. In 2013, a new standard ought to be focused on the next 10 years not the past ten.

===The writing===

The document is poorly written.

====The document is poorly introduced====

The document should start with a discussion of the overall design of the suite of services and what each individual service provides within that suite. This would make it easy for a user to understand the focus of the suite. (The note between requirements~3 and requirement~4, stating that the spec makes no requirements on clients, is really part of the scope of the document and should be front and center.)

The document instead starts with a whole section on REST.

: 1. Scope
: The GeoServices REST API provides a standard way for web clients to communicate with geographic information system (GIS) servers based on Representational State Transfer (REST) principles.

The scope claims that the document identifies resources and a way to use "structured URLs" to exchange those resources between clients and services. If that were true, I would expect
: (1) a list of resources at least as an example, and
: (2) an example of the structure and structuring principles of the URLs.

Section~6 stats this process. Section~6.1 introduces the concept of a root URL for each service and mixes in that that root URL is also a catalog and that the hierarchy offers resources. This all happens in a single, overly compact paragraph. This section needs an editorial rewrite for clarity separating
: (1) the end point,
: (2) the catalog,
: (3) the URL hierarchy,
: (4) the resources, and
: (5) interaction of clients with the URLs through the exchange (get/post) of the resources to the different URLs.

Unfortunately, section~6 then decays into a meandering discussion of REST which mentions the buzzword a lot but does not discuss the aspects of REST design that have been met by the suite and those that have not. If REST is a form of design which offers certain benefits, OGC standards should be discussing the benefits achieved not the buzz word. To what extent are the resources cachable and how do clients and servers agree on that? To what extent are the endpoints and actions on those endpoints discoverable, and how? Those are the issues of RESTful design.

Section~6.3 discusses Resources but immediately then states:

: Each resource has a unique URL. Resources MAY support parameters.

which is a discussion of the URL hierarchy. (And 'Resources' do not 'support parameters'! Services may 'handle requests containing parameters' if that is what is meant.) Then the standard introduces a new idea 'Controller Resources' which are able to 'edit' and 'query'!? A web search does not reveal any formal discussion of 'Controller Resource' so this new type of resource probably deserves some kind of formal introduction.

Section~6.3.3 is not really about resources but the fact that the URL hierarchy is not discoverable from the Resources themselves.

Section~6.3.4 does give a list of resources, but since 'image' is not part of it but will be used by the Service for Map Images, I surmise that the list is of the things 'we have designed a JSON representation for' rather than a list of 'the resources identified and exchanged in the service suite' which is what I expect in an introductory design.

This introduction therefore needs a substantial editorial rewrite to be effective in its goal of explaining what the suite of standards actually does.

This criticism is not limited to the core document.

The Service for Maps document also starts without setting out the five core elements (end pt, catalog?, URL hierarchy, resources, and interactions).

Section~6 of the Service for Maps part, in the middle of the second paragraph, introduces a new concept, with capitalized letters:

: The Map Service Root resource includes a tables property ...

without giving us any clue what this is. It "provides basic information" (perhaps it is a data structure?) but it also "supports several operations" (maybe it's a magical 'Controller Resource'). To me, this just reads as 'the authors of the spec are confused and imprecise in their written language'.

Then, in the figure of 'Resources,' there is actually a resource called 'All layers and tables'. Sorry, but this reader needs some real help to understand what that resource might be.

==== The document requirements are poor ====

The very first requirement, Requirement~1 of the Core document, states:

: Req 1 If a request uses the HTTP GET method, the processing of the request by the service SHALL be safe and idempotent as specified by RFC 2616, 9.1.

This is a *ridiculous* requirement, completely untestable, and explicitly what the Mod Spec should be preventing with its attempt to require all injunctive language to be accompanied by formal tests. The formal test indeed shows that the requirement is untestable.

: Inspect the documentation of the implementation to identify, if requests specified in the GeoServices REST API standard that support the HTTP GET method, are all safe and idempotent, i.e. free of side- effects, as specified in HTTP (RFC 2616, section 9.1). Alternatively, ask the developer of the the service.

: Note that it is not possible to run automated tests against a service to verify conformance with the requirement (and IETF provides no test for conformance with HTTP either). In the absence of such tests, a statement of the developers of the service is sufficient indication that the requirement was addressed.

So essentially this requirement is met if the developers say 'yeah, we thought about it.' In other words, requirement 1 of the whole shebang is a recommendation. Contrast this with requirement 2 which has a nice test defined for it and is a good, solid requirement.

Again, broadening the critique to the Services for Maps, its first requirement states:

: Req 1 The Map Service Root resource SHALL accept requests that conform to the URI template in Table and use any HTTP method identified in the same table.

but the test is then completely irrelevant. At the protocol level, all web services 'shall accept' request messages, so we are not discussing that. A functional test for this 'shall accept' is to construct all valid requests and see that the service never returns an exception to those requests. Even worse, the first test is a catch all 'please test the service here' test. This is *not* a well written specification of the tests for the injunctions of the Service for Maps.

The requirements need a complete, systematic review to see that they work, they are testable, and have good tests.

==== The document has numerous other issues which need resolution ====

* There is no discussion of the overlap of the f= parameter and of the HTTP format header. What happens if they conflict?
* The lack of full integration of the four core HTTP verbs, notably DELETE and PUT, exists merely for backwards compatibility not for forwards progress.
* Requirement~3 blocks forwards progress and experimentation with no explanation as to its importance.
* This goes on and on. This is the work for an EDITOR. I am not interested in doing that work.

= Further Concerns =
--- DRAFT ____

''Please add concerns as bullet points below. Try to be concise. 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 ==

* 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.
* 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.
* 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 ==

* 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 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.

= References =
* 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
** Adrian Custer's eloquent, unbiased, concise summary of the technical issues: 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-10T15:46:28Z

Wiki-Acuster: /* Summary */

This wiki page aims to collate community concerns related to the proposed acceptance of the "Geoservices REST API" becoming an OGC standard. It is being collaboratively edited, targeting completion before the end of May 2013.

= 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, which 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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[User:Hfpmartins | Hugo Martins]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], WebGIS Developer, OSGeo-Portugal Member
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member

= Summary =

The document titled "GeoServices REST API" is currently, in May 2013, being considered as a standard of the Open Geospatial Consortium (OGC). 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 JSON format.

The adoption of the document is contentious for a wide variety of reasons including:

* the process through which it was developed,
* the language of 'REST' and 'API' used by the document,
* the names of the standard and of the services is confusing
* the duplication of these new services with other services standardized by the OGC such as WMS, WFS, WCS, and WPS and with work, by those services, of adopting RESTful designs including URL hierarchies and JSON exchange formats,
* the specific format of JSON messages used, and
* the dominance of the vendor of the single complete implementation in the marketplace.

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 of 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 is a feel that adoption of the standard will likely result in a combination of the following:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

These issues have been answered by the authors of the document who state:

* 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, may be 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 of some of these services.

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

= Analysis =
''This section is derived from an email from Adrian Custer, and has been singled out as he has provided a good technical summary of concerns: http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html.''

''Please don't update this section. Instead, forward corrections or suggestions to Adrian.''

== General overview ==

; The pros:
:* The OGC should be in the business of developing good standards, not of choosing which standards should be implemented.
:* The proposers of the document want to make a standard and have followed all the rules of the consortium. 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 an author of standards at the OGC, 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 is, de-facto, in the position of recommending the 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.
:* Adopting a standard implies a desire to maintain the standard, but the desire to support this approach by the OGC membership is limited. The lack of collaboration on this version 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 implemetation.
:* 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 rewrite. (see at end)

The problem for me, is that 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. (On that, I am inclined to let them make their own mistakes.) The path forwards towards harmonizing the services is unclear. There is little good will towards the standard on behalf of the membership. 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 a third way?

Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to build this thing that we want, an integrated suite of simple services built using simple, well defined resources, accessible and usable using the core HTTP verbs, and discoverable through following links. That's the way forwards and why I have wasted a chunk of my life on WMS-Next.

==A Quick Critique of the proposed standard document==

===The name===

The document currently uses a name that is confusing in all discussions on the matter, both internally at the OGC and externally.

(Postnote: the Standards Working Group proposing the document agreed to accept proposals for new names; if they can find a good alternative, they may adopt it.)

===The design===

The document does not show an overall, coherent design to the service suite. This is mostly because the design reflects a suite that [initially] evolved piecemeal at ESRI rather than one designed from the start to meet the needs of a broad swath of users. This is also due because the experts at the OGC did not contribute to an improved design for a multitude of reasons.

The design of the service which does exist is focused on yesteryear. As an apology for the existing design, section~6.2.2 of part 1, Core says that the only HTTP verbs used are GET and PUT because "the API was originally developed several years ago" but that's okay because it enables support for "Microsoft Silverlight" and "Adobe Flex" two standards which are dying rapidly. In 2013, a new standard ought to be focused on the next 10 years not the past ten.

===The writing===

The document is poorly written.

====The document is poorly introduced====

The document should start with a discussion of the overall design of the suite of services and what each individual service provides within that suite. This would make it easy for a user to understand the focus of the suite. (The note between requirements~3 and requirement~4, stating that the spec makes no requirements on clients, is really part of the scope of the document and should be front and center.)

The document instead starts with a whole section on REST.

: 1. Scope
: The GeoServices REST API provides a standard way for web clients to communicate with geographic information system (GIS) servers based on Representational State Transfer (REST) principles.

The scope claims that the document identifies resources and a way to use "structured URLs" to exchange those resources between clients and services. If that were true, I would expect
: (1) a list of resources at least as an example, and
: (2) an example of the structure and structuring principles of the URLs.

Section~6 stats this process. Section~6.1 introduces the concept of a root URL for each service and mixes in that that root URL is also a catalog and that the hierarchy offers resources. This all happens in a single, overly compact paragraph. This section needs an editorial rewrite for clarity separating
: (1) the end point,
: (2) the catalog,
: (3) the URL hierarchy,
: (4) the resources, and
: (5) interaction of clients with the URLs through the exchange (get/post) of the resources to the different URLs.

Unfortunately, section~6 then decays into a meandering discussion of REST which mentions the buzzword a lot but does not discuss the aspects of REST design that have been met by the suite and those that have not. If REST is a form of design which offers certain benefits, OGC standards should be discussing the benefits achieved not the buzz word. To what extent are the resources cachable and how do clients and servers agree on that? To what extent are the endpoints and actions on those endpoints discoverable, and how? Those are the issues of RESTful design.

Section~6.3 discusses Resources but immediately then states:

: Each resource has a unique URL. Resources MAY support parameters.

which is a discussion of the URL hierarchy. (And 'Resources' do not 'support parameters'! Services may 'handle requests containing parameters' if that is what is meant.) Then the standard introduces a new idea 'Controller Resources' which are able to 'edit' and 'query'!? A web search does not reveal any formal discussion of 'Controller Resource' so this new type of resource probably deserves some kind of formal introduction.

Section~6.3.3 is not really about resources but the fact that the URL hierarchy is not discoverable from the Resources themselves.

Section~6.3.4 does give a list of resources, but since 'image' is not part of it but will be used by the Service for Map Images, I surmise that the list is of the things 'we have designed a JSON representation for' rather than a list of 'the resources identified and exchanged in the service suite' which is what I expect in an introductory design.

This introduction therefore needs a substantial editorial rewrite to be effective in its goal of explaining what the suite of standards actually does.

This criticism is not limited to the core document.

The Service for Maps document also starts without setting out the five core elements (end pt, catalog?, URL hierarchy, resources, and interactions).

Section~6 of the Service for Maps part, in the middle of the second paragraph, introduces a new concept, with capitalized letters:

: The Map Service Root resource includes a tables property ...

without giving us any clue what this is. It "provides basic information" (perhaps it is a data structure?) but it also "supports several operations" (maybe it's a magical 'Controller Resource'). To me, this just reads as 'the authors of the spec are confused and imprecise in their written language'.

Then, in the figure of 'Resources,' there is actually a resource called 'All layers and tables'. Sorry, but this reader needs some real help to understand what that resource might be.

==== The document requirements are poor ====

The very first requirement, Requirement~1 of the Core document, states:

: Req 1 If a request uses the HTTP GET method, the processing of the request by the service SHALL be safe and idempotent as specified by RFC 2616, 9.1.

This is a *ridiculous* requirement, completely untestable, and explicitly what the Mod Spec should be preventing with its attempt to require all injunctive language to be accompanied by formal tests. The formal test indeed shows that the requirement is untestable.

: Inspect the documentation of the implementation to identify, if requests specified in the GeoServices REST API standard that support the HTTP GET method, are all safe and idempotent, i.e. free of side- effects, as specified in HTTP (RFC 2616, section 9.1). Alternatively, ask the developer of the the service.

: Note that it is not possible to run automated tests against a service to verify conformance with the requirement (and IETF provides no test for conformance with HTTP either). In the absence of such tests, a statement of the developers of the service is sufficient indication that the requirement was addressed.

So essentially this requirement is met if the developers say 'yeah, we thought about it.' In other words, requirement 1 of the whole shebang is a recommendation. Contrast this with requirement 2 which has a nice test defined for it and is a good, solid requirement.

Again, broadening the critique to the Services for Maps, its first requirement states:

: Req 1 The Map Service Root resource SHALL accept requests that conform to the URI template in Table and use any HTTP method identified in the same table.

but the test is then completely irrelevant. At the protocol level, all web services 'shall accept' request messages, so we are not discussing that. A functional test for this 'shall accept' is to construct all valid requests and see that the service never returns an exception to those requests. Even worse, the first test is a catch all 'please test the service here' test. This is *not* a well written specification of the tests for the injunctions of the Service for Maps.

The requirements need a complete, systematic review to see that they work, they are testable, and have good tests.

==== The document has numerous other issues which need resolution ====

* There is no discussion of the overlap of the f= parameter and of the HTTP format header. What happens if they conflict?
* The lack of full integration of the four core HTTP verbs, notably DELETE and PUT, exists merely for backwards compatibility not for forwards progress.
* Requirement~3 blocks forwards progress and experimentation with no explanation as to its importance.
* This goes on and on. This is the work for an EDITOR. I am not interested in doing that work.

= Further Concerns =
--- DRAFT ____

''Please add concerns as bullet points below. Try to be concise. 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 ==

* 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.
* 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.
* 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 ==

* 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 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.

= References =
* 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
** Adrian Custer's eloquent, unbiased, concise summary of the technical issues: 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-10T15:44:34Z

Wiki-Acuster: /* Summary */

This wiki page aims to collate community concerns related to the proposed acceptance of the "Geoservices REST API" becoming an OGC standard. It is being collaboratively edited, targeting completion before the end of May 2013.

= 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, which 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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[User:Hfpmartins | Hugo Martins]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], WebGIS Developer, OSGeo-Portugal Member
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member

= Summary =

The document titled "GeoServices REST API" is currently, in May 2013, being considered as a standard of the Open Geospatial Consortium (OGC). 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 JSON format.

The adoption of the document is contentious for a wide variety of reasons including:

* the process through which it was developed,
* the language of 'REST' and 'API' used by the document,
* the names of the standard and of the services is confusing
* the duplication of these new services with other services standardized by the OGC such as WMS, WFS, WCS, and WPS and with work, by those services, of adopting RESTful designs including URL hierarchies and JSON exchange formats,
* the specific format of JSON messages used, and
* the dominance of the vendor of the single complete implementation in the marketplace.

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 of 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 is a feel that adoption of the standard will likely result in a combination of the following:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

These issues have been answered by the authors of the document who state:

* 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, may be 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 of some of these services.

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

= Analysis =
''This section is derived from an email from Adrian Custer, and has been singled out as he has provided a good technical summary of concerns: http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html.''

''Please don't update this section. Instead, forward corrections or suggestions to Adrian.''

== General overview ==

; The pros:
:* The OGC should be in the business of developing good standards, not of choosing which standards should be implemented.
:* The proposers of the document want to make a standard and have followed all the rules of the consortium. 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 an author of standards at the OGC, 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 is, de-facto, in the position of recommending the 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.
:* Adopting a standard implies a desire to maintain the standard, but the desire to support this approach by the OGC membership is limited. The lack of collaboration on this version 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 implemetation.
:* 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 rewrite. (see at end)

The problem for me, is that 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. (On that, I am inclined to let them make their own mistakes.) The path forwards towards harmonizing the services is unclear. There is little good will towards the standard on behalf of the membership. 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 a third way?

Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to build this thing that we want, an integrated suite of simple services built using simple, well defined resources, accessible and usable using the core HTTP verbs, and discoverable through following links. That's the way forwards and why I have wasted a chunk of my life on WMS-Next.

==A Quick Critique of the proposed standard document==

===The name===

The document currently uses a name that is confusing in all discussions on the matter, both internally at the OGC and externally.

(Postnote: the Standards Working Group proposing the document agreed to accept proposals for new names; if they can find a good alternative, they may adopt it.)

===The design===

The document does not show an overall, coherent design to the service suite. This is mostly because the design reflects a suite that [initially] evolved piecemeal at ESRI rather than one designed from the start to meet the needs of a broad swath of users. This is also due because the experts at the OGC did not contribute to an improved design for a multitude of reasons.

The design of the service which does exist is focused on yesteryear. As an apology for the existing design, section~6.2.2 of part 1, Core says that the only HTTP verbs used are GET and PUT because "the API was originally developed several years ago" but that's okay because it enables support for "Microsoft Silverlight" and "Adobe Flex" two standards which are dying rapidly. In 2013, a new standard ought to be focused on the next 10 years not the past ten.

===The writing===

The document is poorly written.

====The document is poorly introduced====

The document should start with a discussion of the overall design of the suite of services and what each individual service provides within that suite. This would make it easy for a user to understand the focus of the suite. (The note between requirements~3 and requirement~4, stating that the spec makes no requirements on clients, is really part of the scope of the document and should be front and center.)

The document instead starts with a whole section on REST.

: 1. Scope
: The GeoServices REST API provides a standard way for web clients to communicate with geographic information system (GIS) servers based on Representational State Transfer (REST) principles.

The scope claims that the document identifies resources and a way to use "structured URLs" to exchange those resources between clients and services. If that were true, I would expect
: (1) a list of resources at least as an example, and
: (2) an example of the structure and structuring principles of the URLs.

Section~6 stats this process. Section~6.1 introduces the concept of a root URL for each service and mixes in that that root URL is also a catalog and that the hierarchy offers resources. This all happens in a single, overly compact paragraph. This section needs an editorial rewrite for clarity separating
: (1) the end point,
: (2) the catalog,
: (3) the URL hierarchy,
: (4) the resources, and
: (5) interaction of clients with the URLs through the exchange (get/post) of the resources to the different URLs.

Unfortunately, section~6 then decays into a meandering discussion of REST which mentions the buzzword a lot but does not discuss the aspects of REST design that have been met by the suite and those that have not. If REST is a form of design which offers certain benefits, OGC standards should be discussing the benefits achieved not the buzz word. To what extent are the resources cachable and how do clients and servers agree on that? To what extent are the endpoints and actions on those endpoints discoverable, and how? Those are the issues of RESTful design.

Section~6.3 discusses Resources but immediately then states:

: Each resource has a unique URL. Resources MAY support parameters.

which is a discussion of the URL hierarchy. (And 'Resources' do not 'support parameters'! Services may 'handle requests containing parameters' if that is what is meant.) Then the standard introduces a new idea 'Controller Resources' which are able to 'edit' and 'query'!? A web search does not reveal any formal discussion of 'Controller Resource' so this new type of resource probably deserves some kind of formal introduction.

Section~6.3.3 is not really about resources but the fact that the URL hierarchy is not discoverable from the Resources themselves.

Section~6.3.4 does give a list of resources, but since 'image' is not part of it but will be used by the Service for Map Images, I surmise that the list is of the things 'we have designed a JSON representation for' rather than a list of 'the resources identified and exchanged in the service suite' which is what I expect in an introductory design.

This introduction therefore needs a substantial editorial rewrite to be effective in its goal of explaining what the suite of standards actually does.

This criticism is not limited to the core document.

The Service for Maps document also starts without setting out the five core elements (end pt, catalog?, URL hierarchy, resources, and interactions).

Section~6 of the Service for Maps part, in the middle of the second paragraph, introduces a new concept, with capitalized letters:

: The Map Service Root resource includes a tables property ...

without giving us any clue what this is. It "provides basic information" (perhaps it is a data structure?) but it also "supports several operations" (maybe it's a magical 'Controller Resource'). To me, this just reads as 'the authors of the spec are confused and imprecise in their written language'.

Then, in the figure of 'Resources,' there is actually a resource called 'All layers and tables'. Sorry, but this reader needs some real help to understand what that resource might be.

==== The document requirements are poor ====

The very first requirement, Requirement~1 of the Core document, states:

: Req 1 If a request uses the HTTP GET method, the processing of the request by the service SHALL be safe and idempotent as specified by RFC 2616, 9.1.

This is a *ridiculous* requirement, completely untestable, and explicitly what the Mod Spec should be preventing with its attempt to require all injunctive language to be accompanied by formal tests. The formal test indeed shows that the requirement is untestable.

: Inspect the documentation of the implementation to identify, if requests specified in the GeoServices REST API standard that support the HTTP GET method, are all safe and idempotent, i.e. free of side- effects, as specified in HTTP (RFC 2616, section 9.1). Alternatively, ask the developer of the the service.

: Note that it is not possible to run automated tests against a service to verify conformance with the requirement (and IETF provides no test for conformance with HTTP either). In the absence of such tests, a statement of the developers of the service is sufficient indication that the requirement was addressed.

So essentially this requirement is met if the developers say 'yeah, we thought about it.' In other words, requirement 1 of the whole shebang is a recommendation. Contrast this with requirement 2 which has a nice test defined for it and is a good, solid requirement.

Again, broadening the critique to the Services for Maps, its first requirement states:

: Req 1 The Map Service Root resource SHALL accept requests that conform to the URI template in Table and use any HTTP method identified in the same table.

but the test is then completely irrelevant. At the protocol level, all web services 'shall accept' request messages, so we are not discussing that. A functional test for this 'shall accept' is to construct all valid requests and see that the service never returns an exception to those requests. Even worse, the first test is a catch all 'please test the service here' test. This is *not* a well written specification of the tests for the injunctions of the Service for Maps.

The requirements need a complete, systematic review to see that they work, they are testable, and have good tests.

==== The document has numerous other issues which need resolution ====

* There is no discussion of the overlap of the f= parameter and of the HTTP format header. What happens if they conflict?
* The lack of full integration of the four core HTTP verbs, notably DELETE and PUT, exists merely for backwards compatibility not for forwards progress.
* Requirement~3 blocks forwards progress and experimentation with no explanation as to its importance.
* This goes on and on. This is the work for an EDITOR. I am not interested in doing that work.

= Further Concerns =
--- DRAFT ____

''Please add concerns as bullet points below. Try to be concise. 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 ==

* 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.
* 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.
* 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 ==

* 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 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.

= References =
* 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
** Adrian Custer's eloquent, unbiased, concise summary of the technical issues: 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-10T15:43:16Z

Wiki-Acuster: /* Summary */

This wiki page aims to collate community concerns related to the proposed acceptance of the "Geoservices REST API" becoming an OGC standard. It is being collaboratively edited, targeting completion before the end of May 2013.

= 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, which 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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[User:Hfpmartins | Hugo Martins]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], WebGIS Developer, OSGeo-Portugal Member
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member

= Summary =

The document titled "GeoServices REST API" is currently, in May 2013, being considered as a standard of the Open Geospatial Consortium (OGC). 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 JSON format.

The adoption of the document is contentious for a wide variety of reasons including:

* the process through which it was developed,
* the language of 'REST' and 'API' used by the document,
* the names of the standard and of the services is confusing
* the duplication of these new services with other services standardized by the OGC such as WMS, WFS, WCS, and WPS and with work, by those services, of adopting RESTful designs including URL hierarchies and JSON exchange formats,
* the specific format of JSON messages used, and
* the dominance of the vendor of the single complete implementation in the marketplace.

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 of 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 is a feel that adoption of the standard will likely result in a combination of the following:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

These issues have been answered by the authors of the document who state:

* 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, may be 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 of some of these services.

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

= Analysis =
''This section is derived from an email from Adrian Custer, and has been singled out as he has provided a good technical summary of concerns: http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html.''

''Please don't update this section. Instead, forward corrections or suggestions to Adrian.''

== General overview ==

; The pros:
:* The OGC should be in the business of developing good standards, not of choosing which standards should be implemented.
:* The proposers of the document want to make a standard and have followed all the rules of the consortium. 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 an author of standards at the OGC, 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 is, de-facto, in the position of recommending the 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.
:* Adopting a standard implies a desire to maintain the standard, but the desire to support this approach by the OGC membership is limited. The lack of collaboration on this version 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 implemetation.
:* 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 rewrite. (see at end)

The problem for me, is that 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. (On that, I am inclined to let them make their own mistakes.) The path forwards towards harmonizing the services is unclear. There is little good will towards the standard on behalf of the membership. 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 a third way?

Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to build this thing that we want, an integrated suite of simple services built using simple, well defined resources, accessible and usable using the core HTTP verbs, and discoverable through following links. That's the way forwards and why I have wasted a chunk of my life on WMS-Next.

==A Quick Critique of the proposed standard document==

===The name===

The document currently uses a name that is confusing in all discussions on the matter, both internally at the OGC and externally.

(Postnote: the Standards Working Group proposing the document agreed to accept proposals for new names; if they can find a good alternative, they may adopt it.)

===The design===

The document does not show an overall, coherent design to the service suite. This is mostly because the design reflects a suite that [initially] evolved piecemeal at ESRI rather than one designed from the start to meet the needs of a broad swath of users. This is also due because the experts at the OGC did not contribute to an improved design for a multitude of reasons.

The design of the service which does exist is focused on yesteryear. As an apology for the existing design, section~6.2.2 of part 1, Core says that the only HTTP verbs used are GET and PUT because "the API was originally developed several years ago" but that's okay because it enables support for "Microsoft Silverlight" and "Adobe Flex" two standards which are dying rapidly. In 2013, a new standard ought to be focused on the next 10 years not the past ten.

===The writing===

The document is poorly written.

====The document is poorly introduced====

The document should start with a discussion of the overall design of the suite of services and what each individual service provides within that suite. This would make it easy for a user to understand the focus of the suite. (The note between requirements~3 and requirement~4, stating that the spec makes no requirements on clients, is really part of the scope of the document and should be front and center.)

The document instead starts with a whole section on REST.

: 1. Scope
: The GeoServices REST API provides a standard way for web clients to communicate with geographic information system (GIS) servers based on Representational State Transfer (REST) principles.

The scope claims that the document identifies resources and a way to use "structured URLs" to exchange those resources between clients and services. If that were true, I would expect
: (1) a list of resources at least as an example, and
: (2) an example of the structure and structuring principles of the URLs.

Section~6 stats this process. Section~6.1 introduces the concept of a root URL for each service and mixes in that that root URL is also a catalog and that the hierarchy offers resources. This all happens in a single, overly compact paragraph. This section needs an editorial rewrite for clarity separating
: (1) the end point,
: (2) the catalog,
: (3) the URL hierarchy,
: (4) the resources, and
: (5) interaction of clients with the URLs through the exchange (get/post) of the resources to the different URLs.

Unfortunately, section~6 then decays into a meandering discussion of REST which mentions the buzzword a lot but does not discuss the aspects of REST design that have been met by the suite and those that have not. If REST is a form of design which offers certain benefits, OGC standards should be discussing the benefits achieved not the buzz word. To what extent are the resources cachable and how do clients and servers agree on that? To what extent are the endpoints and actions on those endpoints discoverable, and how? Those are the issues of RESTful design.

Section~6.3 discusses Resources but immediately then states:

: Each resource has a unique URL. Resources MAY support parameters.

which is a discussion of the URL hierarchy. (And 'Resources' do not 'support parameters'! Services may 'handle requests containing parameters' if that is what is meant.) Then the standard introduces a new idea 'Controller Resources' which are able to 'edit' and 'query'!? A web search does not reveal any formal discussion of 'Controller Resource' so this new type of resource probably deserves some kind of formal introduction.

Section~6.3.3 is not really about resources but the fact that the URL hierarchy is not discoverable from the Resources themselves.

Section~6.3.4 does give a list of resources, but since 'image' is not part of it but will be used by the Service for Map Images, I surmise that the list is of the things 'we have designed a JSON representation for' rather than a list of 'the resources identified and exchanged in the service suite' which is what I expect in an introductory design.

This introduction therefore needs a substantial editorial rewrite to be effective in its goal of explaining what the suite of standards actually does.

This criticism is not limited to the core document.

The Service for Maps document also starts without setting out the five core elements (end pt, catalog?, URL hierarchy, resources, and interactions).

Section~6 of the Service for Maps part, in the middle of the second paragraph, introduces a new concept, with capitalized letters:

: The Map Service Root resource includes a tables property ...

without giving us any clue what this is. It "provides basic information" (perhaps it is a data structure?) but it also "supports several operations" (maybe it's a magical 'Controller Resource'). To me, this just reads as 'the authors of the spec are confused and imprecise in their written language'.

Then, in the figure of 'Resources,' there is actually a resource called 'All layers and tables'. Sorry, but this reader needs some real help to understand what that resource might be.

==== The document requirements are poor ====

The very first requirement, Requirement~1 of the Core document, states:

: Req 1 If a request uses the HTTP GET method, the processing of the request by the service SHALL be safe and idempotent as specified by RFC 2616, 9.1.

This is a *ridiculous* requirement, completely untestable, and explicitly what the Mod Spec should be preventing with its attempt to require all injunctive language to be accompanied by formal tests. The formal test indeed shows that the requirement is untestable.

: Inspect the documentation of the implementation to identify, if requests specified in the GeoServices REST API standard that support the HTTP GET method, are all safe and idempotent, i.e. free of side- effects, as specified in HTTP (RFC 2616, section 9.1). Alternatively, ask the developer of the the service.

: Note that it is not possible to run automated tests against a service to verify conformance with the requirement (and IETF provides no test for conformance with HTTP either). In the absence of such tests, a statement of the developers of the service is sufficient indication that the requirement was addressed.

So essentially this requirement is met if the developers say 'yeah, we thought about it.' In other words, requirement 1 of the whole shebang is a recommendation. Contrast this with requirement 2 which has a nice test defined for it and is a good, solid requirement.

Again, broadening the critique to the Services for Maps, its first requirement states:

: Req 1 The Map Service Root resource SHALL accept requests that conform to the URI template in Table and use any HTTP method identified in the same table.

but the test is then completely irrelevant. At the protocol level, all web services 'shall accept' request messages, so we are not discussing that. A functional test for this 'shall accept' is to construct all valid requests and see that the service never returns an exception to those requests. Even worse, the first test is a catch all 'please test the service here' test. This is *not* a well written specification of the tests for the injunctions of the Service for Maps.

The requirements need a complete, systematic review to see that they work, they are testable, and have good tests.

==== The document has numerous other issues which need resolution ====

* There is no discussion of the overlap of the f= parameter and of the HTTP format header. What happens if they conflict?
* The lack of full integration of the four core HTTP verbs, notably DELETE and PUT, exists merely for backwards compatibility not for forwards progress.
* Requirement~3 blocks forwards progress and experimentation with no explanation as to its importance.
* This goes on and on. This is the work for an EDITOR. I am not interested in doing that work.

= Further Concerns =
--- DRAFT ____

''Please add concerns as bullet points below. Try to be concise. 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 ==

* 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.
* 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.
* 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 ==

* 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 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.

= References =
* 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
** Adrian Custer's eloquent, unbiased, concise summary of the technical issues: 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

[[Category: OGC]]
[[Category: Standards]]

Geoservices REST API

2013-05-10T15:41:34Z

Wiki-Acuster: /* Summary */ Rewrite for clarity and balance

This wiki page aims to collate community concerns related to the proposed acceptance of the "Geoservices REST API" becoming an OGC standard. It is being collaboratively edited, targeting completion before the end of May 2013.

= 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, which 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 =

''Please don't edit this "Open Letter" statement, comments and discussion should go below.''

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 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.

== 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
# [[Mark Lucas]], Founding member and board of directors for OSGeo foundation, Prinicipal 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: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]
# Gerhard Triebnig, Managing Director at [http://eox.at EOX IT Services GmbH]
# [[User:pcreso|Brent Wood]], Environmental Information Delivery Programme Leader, NIWA, New Zealand. OGC member, Aust/NZ OSGEO chapter member, NZOSS Council member
# [[User:Schpidi|Stephan Meissl]], CTO at [http://eox.at EOX IT Services GmbH], contributor to [http://mapserver.org Mapserver], PSC chair of [http://eoxserver.org EOxServer]
# [[User:ticheler|Jeroen Ticheler]], Director of [http://geocat.net GeoCat], project founder and PSC chair of [http://geonetwork-opensource.org GeoNetwork opensource]
# [[User:Just|Just van den Broecke]], Director at [http://www.justobjects.nl Just Objects], contributor to [http://heron-mc.org Heron Mapping Client], secretary of [http://osgeo.nl OSGeo Dutch Local Chapter], 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: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: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.
# Bevan Rudge, Director Lucion Limited, IT Advisor at Conservation Strategy Fund, Esri client
# [[User:Delawen|María Arias de Reyna]], software engineer at [http://geocat.net GeoCat], Spain, member of OSGeo Spanish Local Chapter.
# [[User:Aghisla|Anne Ghisla]], OSGeo Board Member, Italy, member of OSGeo Italian Local Chapter.
# [[User:Michogar|Micho Garcia]], Freelance and member of [http://geomati.co geomati.co], Spain, member of Spanish Local Chapter
# [[User:Madi|Margherita Di Leo]], OSGeo Charter Member, Post-doctoral researcher at the European Commission, JRC, Italy
# [[Jorge Sanz]], GIS Consultant at [http://www.prodevelop.es Prodevelop], OSGeo Charter Member, OSGeo Spanish Local Chapter Member, Spain
# [[Pablo Sanxiao]], CTO and co-founder at [http://www.icarto.es iCarto], OSGeo Spanish Local Chapter Member, Spain
# [[User:Fsteggink|Frank Steggink]], GIS software developer at [http://www.vicrea.nl Vicrea], The Netherlands, member of the Dutch Local Chapter
# [[User:Olivier.courtin|Olivier Courtin]], [http://www.oslandia.com Oslandia] co-founder, core contributor or/and PSC member of [http://mapserver.org Mapserver] and [http://www.postgis.org/ PostGIS]. OGC TC member.
# [[User:Bolosig|Wladimir Szczerban]], OSGeo Spanish Local Chapter Member, Spain
# [[User:AnitaGraser|Anita Graser]], GIS specialist with AIT Austrian Institute of Technology, OSGeo Charter member and QGIS team member.
# [[User:Vmische|Volker Mische]], geospatial software engineer, creator of GeoCouch
# [[User:Ivansanchez|Iván Sánchez]], OSGeo Spanish Local Chapter Member, head of [http://www.openstreetmap.es OpenStreetMap Spain], [http://osmfoundation.org OpenStreetMap Foundation] member, [http://hot.openstreetmap.org/ Humanitarian OpenStreetMap Team] member, [http://www.idee.es/ Spanish SDI working group] member
# [[User:Gabi|Gabriel Carrión]], Strategy Manager at [http://www.gvsig.com gvSIG association]
# [http://strk.keybit.net Sandro Santilli], OSGeo Charter Member, [http://postgis.net PostGIS] and [http://trac.osgeo.org/geos GEOS] PSC member and core hacker.
# [[User:Javiarch|Javier Diaz]], member of Geoinquietos Bs As [http://wiki.osgeo.org/wiki/Category:Geoinquietos_Buenos_Aires], member of the Organizing Committee FOSS4G Bs As 2013 [http://www.foss4g-ba.org/]
# [[User: JoCook|Jo Cook]], Consultant at [http://isharemaps.com| Astun Technology], former Director of OSGeo, Charter Member, founder of UK Local Chapter, Deputy Chair of [http://2013.foss4g.org| FOSS4G 2013]
# [[User: Fpenarru | Francisco José Peñarrubia]], CTO and co-founder at [http://www.scolab.es SCOLAB]. Members of [http://www.gvsig.com gvSIG Association]
# [[User: Ganesh|Shanmugam Ganeshkumar]], Director of [http://www.geoicon.com GeoICON], member OSGeo Malaysia Chapter
# [[User:Barryrowlingson|Barry Rowlingson]], Senior Researcher, Lancaster University and Software Sustainability Institute Fellow
# [[User: Sfkeller|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)
# [[User: AndyBMapMan|Andrew Bailey]], OSGeo member, Astun Technology
# [[User: Sanand|Suchith Anand]], OSGeo Charter member, OSGeo Education member, FOSS4G 2013 LOC member
# [[User: krefftc|Carlos Krefft]], GIS software developer at [http://www.cstars.miami.edu CSTARS - University of Miami], OGC and OSGeo Member.
# [[User:Steko|Stefano Costa]], OSGeo member, GFOSS.it member and former board member, Ministero per i Beni e le Attività Culturali (Italy)
# [[User:pebau|Peter Baumann]], [http://www.jacobs-university.de/lsis 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)
# [[User:pmbatty|Peter Batty]], CTO of Geospatial Division at [http://www.ubisense.net Ubisense], OSGeo board member, former CTO of [http://intergraph.com Intergraph] and [http://www.gedigitalenergy.com/gis.htm GE Smallworld], Technical Committee member of OGC in its formative years c 1995-97
# [[User: BarendKobben | Barend Köbben]], OSGEO Chartered Member, OSGeo.nl Dutch chapter treasurer, Senior Lecturer at [http://www.itc.nl ITC-University of Twente]
# [[User: pcav | Paolo Cavallini]], [http://www.faunalia.it Faunalia], OSGeo member, GFOSS.it member and former president, QGIS-PSC
# [[User: fthamura| FRans Thamura]], [http://www.osgeo.or.id Indonesia], OSGeo Indonesia, organizer]
# [[User: Endofcap| Sanghee Shin]], Founder and CEO of [http://www.gaia3d.com Gaia3D], OSGeo Charter Member, Representative of [http://www.osgeo.kr OSGeo Korean Chapter], Chairman of Open Source GIS Alliance Korea
# [[User: rentairo| Benni Purwonegoro]],Indonesia, IT-Spatial Engineer @ Geospatial Information Agency .
# [[User: jachym| Jachym Cepicky]], Czech Republic, member of OSGeo Board of Directors
# [[User: cappelaere| Pat Cappelaere]], Vightel Corporation
# [[User: JuergenFischer|Jürgen Fischer]], norBIT GmbH, QGIS core developer
# [[User: Maria|Maria Antonia Brovelli]], OSGeo Charter member, OSGeo Education member, GIS Professor and Vice Rector for the Como Campus at [http://www.polimi.it/en Politecnico di Milano], Italy
# [[User:Nachouve |Nacho Varela]], GIS Consultant, OSGeo Spanish Local Chapter Member, Spain
# [[User:vasile |Vasile Craciunescu]], OSGeo Charter member, OSGeo Romania Local Chapter Leader, Researcher at Romanian National Meteorological Administration, Romania
# [[User:badaveil |Abbas Abdul Wahab]], Asst. Director, Federal Department of Town & Country Planning, Peninsular Malaysia
# [[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:Lutra | Giovanni Manghi]], Portugal, [http://www.faunalia.pt Faunalia], OSGeo member, OSGeo-Portugal
# [[User:Hfpmartins | Hugo Martins]], UK, [http://www.lutraconsulting.co.uk Lutra Consulting], WebGIS Developer, OSGeo-Portugal Member
# [[User:SGijzen | Sidney Gijzen]], The Netherlands, Researcher GIS @ [http://www.wageningenur.nl/en/Expertise-Services/Research-Institutes/alterra.htm Alterra, Wageningen UR]
# [[User:mfidelman | Miles Fidelman]], US, Principal, Protocol Technologies Group, LLC
# [[User:punkish | Puneet Kishor]], OSGeo Charter Member; [http://www.geology.wisc.edu Geology, Univ. of Wisconsin-Madison]; [http://creativecommons.org/staff#puneetkishor Creative Commons]
# [[User:Toze | António José Silva]], Portugal, GIS Consultant, OSGeo-Portugal Member

= Summary =

The document titled "GeoServices REST API" is currently, in May 2013, being considered as a standard of the Open Geospatial Consortium (OGC). 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 [[on the request for public comment page][http://www.opengeospatial.org/standards/requests/89]] (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 JSON format.

The adoption of the document is contentious for a wide variety of reasons including:

* the process through which it was developed,
* the language of 'REST' and 'API' used by the document,
* the names of the standard and of the services is confusing
* the duplication of these new services with other services standardized by the OGC such as WMS, WFS, WCS, and WPS and with work, by those services, of adopting RESTful designs including URL hierarchies and JSON exchange formats,
* the specific format of JSON messages used, and
* the dominance of the vendor of the single complete implementation in the marketplace.

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 of 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 is a feel that adoption of the standard will likely result in a combination of the following:
# The cost to application developers, systems integrators, testers and sponsors to support all relevant OGC standards will be substantially increased.
# Consequently, organisations and/or applications may choose to only support one standard, or only support one standard fully.
# 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.
# 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.
# 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.

These issues have been answered by the authors of the document who state:

* 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, may be 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 of some of these services.

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

= Analysis =
''This section is derived from an email from Adrian Custer, and has been singled out as he has provided a good technical summary of concerns: http://lists.osgeo.org/pipermail/discuss/2013-May/011667.html.''

''Please don't update this section. Instead, forward corrections or suggestions to Adrian.''

== General overview ==

; The pros:
:* The OGC should be in the business of developing good standards, not of choosing which standards should be implemented.
:* The proposers of the document want to make a standard and have followed all the rules of the consortium. 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 an author of standards at the OGC, 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 is, de-facto, in the position of recommending the 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.
:* Adopting a standard implies a desire to maintain the standard, but the desire to support this approach by the OGC membership is limited. The lack of collaboration on this version 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 implemetation.
:* 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 rewrite. (see at end)

The problem for me, is that 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. (On that, I am inclined to let them make their own mistakes.) The path forwards towards harmonizing the services is unclear. There is little good will towards the standard on behalf of the membership. 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 a third way?

Well, actually, there is. The natural consequence of either decision is a renewed commitment towards trying to build this thing that we want, an integrated suite of simple services built using simple, well defined resources, accessible and usable using the core HTTP verbs, and discoverable through following links. That's the way forwards and why I have wasted a chunk of my life on WMS-Next.

==A Quick Critique of the proposed standard document==

===The name===

The document currently uses a name that is confusing in all discussions on the matter, both internally at the OGC and externally.

(Postnote: the Standards Working Group proposing the document agreed to accept proposals for new names; if they can find a good alternative, they may adopt it.)

===The design===

The document does not show an overall, coherent design to the service suite. This is mostly because the design reflects a suite that [initially] evolved piecemeal at ESRI rather than one designed from the start to meet the needs of a broad swath of users. This is also due because the experts at the OGC did not contribute to an improved design for a multitude of reasons.

The design of the service which does exist is focused on yesteryear. As an apology for the existing design, section~6.2.2 of part 1, Core says that the only HTTP verbs used are GET and PUT because "the API was originally developed several years ago" but that's okay because it enables support for "Microsoft Silverlight" and "Adobe Flex" two standards which are dying rapidly. In 2013, a new standard ought to be focused on the next 10 years not the past ten.

===The writing===

The document is poorly written.

====The document is poorly introduced====

The document should start with a discussion of the overall design of the suite of services and what each individual service provides within that suite. This would make it easy for a user to understand the focus of the suite. (The note between requirements~3 and requirement~4, stating that the spec makes no requirements on clients, is really part of the scope of the document and should be front and center.)

The document instead starts with a whole section on REST.

: 1. Scope
: The GeoServices REST API provides a standard way for web clients to communicate with geographic information system (GIS) servers based on Representational State Transfer (REST) principles.

The scope claims that the document identifies resources and a way to use "structured URLs" to exchange those resources between clients and services. If that were true, I would expect
: (1) a list of resources at least as an example, and
: (2) an example of the structure and structuring principles of the URLs.

Section~6 stats this process. Section~6.1 introduces the concept of a root URL for each service and mixes in that that root URL is also a catalog and that the hierarchy offers resources. This all happens in a single, overly compact paragraph. This section needs an editorial rewrite for clarity separating
: (1) the end point,
: (2) the catalog,
: (3) the URL hierarchy,
: (4) the resources, and
: (5) interaction of clients with the URLs through the exchange (get/post) of the resources to the different URLs.

Unfortunately, section~6 then decays into a meandering discussion of REST which mentions the buzzword a lot but does not discuss the aspects of REST design that have been met by the suite and those that have not. If REST is a form of design which offers certain benefits, OGC standards should be discussing the benefits achieved not the buzz word. To what extent are the resources cachable and how do clients and servers agree on that? To what extent are the endpoints and actions on those endpoints discoverable, and how? Those are the issues of RESTful design.

Section~6.3 discusses Resources but immediately then states:

: Each resource has a unique URL. Resources MAY support parameters.

which is a discussion of the URL hierarchy. (And 'Resources' do not 'support parameters'! Services may 'handle requests containing parameters' if that is what is meant.) Then the standard introduces a new idea 'Controller Resources' which are able to 'edit' and 'query'!? A web search does not reveal any formal discussion of 'Controller Resource' so this new type of resource probably deserves some kind of formal introduction.

Section~6.3.3 is not really about resources but the fact that the URL hierarchy is not discoverable from the Resources themselves.

Section~6.3.4 does give a list of resources, but since 'image' is not part of it but will be used by the Service for Map Images, I surmise that the list is of the things 'we have designed a JSON representation for' rather than a list of 'the resources identified and exchanged in the service suite' which is what I expect in an introductory design.

This introduction therefore needs a substantial editorial rewrite to be effective in its goal of explaining what the suite of standards actually does.

This criticism is not limited to the core document.

The Service for Maps document also starts without setting out the five core elements (end pt, catalog?, URL hierarchy, resources, and interactions).

Section~6 of the Service for Maps part, in the middle of the second paragraph, introduces a new concept, with capitalized letters:

: The Map Service Root resource includes a tables property ...

without giving us any clue what this is. It "provides basic information" (perhaps it is a data structure?) but it also "supports several operations" (maybe it's a magical 'Controller Resource'). To me, this just reads as 'the authors of the spec are confused and imprecise in their written language'.

Then, in the figure of 'Resources,' there is actually a resource called 'All layers and tables'. Sorry, but this reader needs some real help to understand what that resource might be.

==== The document requirements are poor ====

The very first requirement, Requirement~1 of the Core document, states:

: Req 1 If a request uses the HTTP GET method, the processing of the request by the service SHALL be safe and idempotent as specified by RFC 2616, 9.1.

This is a *ridiculous* requirement, completely untestable, and explicitly what the Mod Spec should be preventing with its attempt to require all injunctive language to be accompanied by formal tests. The formal test indeed shows that the requirement is untestable.

: Inspect the documentation of the implementation to identify, if requests specified in the GeoServices REST API standard that support the HTTP GET method, are all safe and idempotent, i.e. free of side- effects, as specified in HTTP (RFC 2616, section 9.1). Alternatively, ask the developer of the the service.

: Note that it is not possible to run automated tests against a service to verify conformance with the requirement (and IETF provides no test for conformance with HTTP either). In the absence of such tests, a statement of the developers of the service is sufficient indication that the requirement was addressed.

So essentially this requirement is met if the developers say 'yeah, we thought about it.' In other words, requirement 1 of the whole shebang is a recommendation. Contrast this with requirement 2 which has a nice test defined for it and is a good, solid requirement.

Again, broadening the critique to the Services for Maps, its first requirement states:

: Req 1 The Map Service Root resource SHALL accept requests that conform to the URI template in Table and use any HTTP method identified in the same table.

but the test is then completely irrelevant. At the protocol level, all web services 'shall accept' request messages, so we are not discussing that. A functional test for this 'shall accept' is to construct all valid requests and see that the service never returns an exception to those requests. Even worse, the first test is a catch all 'please test the service here' test. This is *not* a well written specification of the tests for the injunctions of the Service for Maps.

The requirements need a complete, systematic review to see that they work, they are testable, and have good tests.

==== The document has numerous other issues which need resolution ====

* There is no discussion of the overlap of the f= parameter and of the HTTP format header. What happens if they conflict?
* The lack of full integration of the four core HTTP verbs, notably DELETE and PUT, exists merely for backwards compatibility not for forwards progress.
* Requirement~3 blocks forwards progress and experimentation with no explanation as to its importance.
* This goes on and on. This is the work for an EDITOR. I am not interested in doing that work.

= Further Concerns =
--- DRAFT ____

''Please add concerns as bullet points below. Try to be concise. 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 ==

* 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.
* 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.
* 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 ==

* 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 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.

= References =
* 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
** Adrian Custer's eloquent, unbiased, concise summary of the technical issues: 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

[[Category: OGC]]
[[Category: Standards]]

Project Copyright Assignment

2012-07-18T15:57:49Z

Wiki-Acuster: Fix broken link

'''The [http://download.osgeo.org/osgeo/legal/GeotoolsAssignmentToOSGeo.pdf GeoTools Copyright Assignment] agreement is also now approved for use and may be considered superior to the following template for some purposes.''' This document is available in other formats from the [http://download.osgeo.org/osgeo/legal/ same folder] or from the [http://docs.codehaus.org/display/GEOT/1+Contributors GeoTools Developers Guide].

= COPYRIGHT ASSIGNMENT =

This Copyright Assignment is for use by contributors who wish to assign the copyright to their
software code contributions to The Open Source Geospatial Foundation, a Delaware not-for-
profit corporation (“OSGeo”). OSGeo typically obtains contributions of software code by way of
a license grant from the contributor; OSGeo does not require that contributors to its projects
assign their copyright to the foundation. However, many contributors have expressed a desire to
do so. This document is designed to allow you to assign the copyright in your code contributions
to OSGeo secure in the knowledge that your contributions will be maintained for public benefit.
At the same time, OSGeo grants you the freedom to continue using your contributions in any
manner you wish.

By signing this Copyright Assignment, you understand and agree as follows:

1. '''“Contributions” Defined.''' “Contributions” means all past, present, and future computer code
you have contributed, are contributing or will contribute to any OSGeo project, including binary
and source code and any accompanying documentation and files, and anything else described
below:
(for example, “All code submitted in connection with the Foo project”):
__________________________________________________
__________________________________________________
__________________________________________________
__________________________________________________

2. '''License Terms.''' OSGeo will make the Contributions available under a license certified by the
Open Source Initiative and may also make the Contributions available under other license terms.

3. '''Intellectual Property Rights.''' You agree that you alone created the Contributions, and that
you own and have sufficient legal rights to contribute the Contributions to OSGeo in accordance
with the terms of this Copyright Assignment, and that you will not provide any Contributions that
violate any law or breach any contract. If a third party, such as your employer, may have rights to
intellectual property you create (“IP Rights”), you agree that such third party has (1) no IP Rights
in the Contributions; (2) granted sufficient written permission for this assignment; or (3) waived
its IP Rights in the Contributions in writing. You agree the Contributions are submitted without
any obligation to keep those Contributions confidential.

4. '''Assignment.''' You hereby assign to OSGeo all worldwide common law and statutory rights in
or associated with the copyrights and all other right, title and interest you now or may in the
future have in and relating to the Contributions and all applications for registration of the
Contributions (all of which are part of the definition of “Contributions”) to the extent allowable
under applicable local laws and copyright conventions. This assignment includes all rights of
paternity, integrity, disclosure and withdrawal and any other rights that may be referred to as
“moral rights,” “artist’s rights,” “droit moral,” or the like. You hereby provide any and all
ratifications and consents necessary to accomplish the purposes of the foregoing to the extent
possible. To the extent this assignment is not effective, you grant OSGeo a worldwide, non-
exclusive, royalty-free, perpetual, irrevocable, sublicensable and fully paid-up right to use,
modify, create derivative works of, perform, display, reproduce and distribute the Contributions.

5. '''Ongoing Assistance.''' You agree at the request and expense of OSGeo to execute any
documents or perform any actions which OSGeo may request to perfect this assignment or
otherwise implement this Copyright Assignment. You agree that this Copyright Assignment may
be submitted by OSGeo to register a copyright in the Contributions.

6. '''OSGeo’s License to You.''' OSGeo hereby grants to you a worldwide, non-exclusive, royalty-
free, perpetual, and fully paid-up right to use, modify create derivative works of, perform,
display, reproduce and distribute the Contributions in any manner you wish.

7. '''Limitations.''' Except as set forth herein, the Contributions are provided “AS-IS” and without
any express or implied warranties of any kind, including any implied warranties of
merchantability, fitness for a particular purpose, and noninfringement.

8. '''Miscellaneous terms.''' This Copyright Assignment constitutes the entire agreement between
you and OSGeo with respect to the subject matter herein, and supersedes any prior or
contemporaneous agreements, written or oral. This Copyright Assignment may be modified only
by a written agreement signed by both you and OSGeo. This Copyright Assignment shall be
governed by and enforced in accordance with the laws of the State of California, without giving
effect to any conflicts of law principles.

ACCEPTED AND AGREED:
____________________________
(signature)
____________________________
(print name)
____________________________
(date)

[[Category: Incubation]]

Benchmarking 2010/Constellation-SDI

2010-09-08T13:42:12Z

Wiki-Acuster: Add DBF fix

This page describes the experience of the Constellation-SDI team during the FOSS4G 2010 Benchmarking effort.

== Benchmark design ==

We expended a great deal of effort attempting to understand how a benchmarking effort could be designed properly.

The 2009 and 2010 efforts were undertaken in the naive belief that one simply sets up different servers on the same data and makes requests of the servers to compare response times. Belatedly, the 2010 effort is demonstrating that a proper benchmark is more complex, since the data might be in a format useful for a certain class of use cases but meaningless for another scale of usage, the testing can easily be hardware bound limiting useful comparison between servers, servers can be set up to be doing very different work especially in 'best effort'/anything goes configurations, and results can be compared only in superficial ways or in very narrow types of requests. In order to tackle these issues rather than merely pretend they were not serious, we examined what it would take to develop a useful benchmarking protocol, either to stress all the functionality of one particular server or to compare the performance and abilities of various, arbitrary WMS servers.

Developing a WMS benchmarking design which provides useful, comparative metrics of server performance is exceedingly hard. In a recent presentation at the Java Language Summit, Joshua Bloch presented a talk entitled [http://wiki.jvmlangsummit.com/images/1/1d/PerformanceAnxiety2010.pdf ''Performance Anxiety''] which describes the impossibility of developing performant software from first principles in any language due to the enhancements of compilation and machine instruction re-ordering, the necessity of testing to obtain concrete results, and the difficulty of developing proper, statistically rigourous testing metrics.

Since these issues were apparent to us even before this effort, we have been developing tools, benchmark designs and analytic methodologies to test the Constellation-SDI server. This work has been greatly extended during the FOSS4G 2010 benchmarking effort and expanded to consider how to test different WMS servers, possibly built for different uses.

Unfortunately, there is still much distance to go before achieving a solid benchmarking suite. This work will undoubtedly be continued in the future, most likely within the framework of Open Geospatial Consortium (OGC) testing.

== Enhancements ==

This section describes enhancements due to the work during the benchmarking 2010 effort, including improved understanding and workflow by the Constellation-SDI team and ameliorations to the code bases of the [http://www.geotoolkit.org/ Geotoolkit.org] library and to the [http://www.constellation-sdi.org Constellation-SDI] server itself.

=== Benchmarking ===

* Investigate numerous issues with jmeter.
* Design simpler scripts.
* Examine different configurations to stress different aspects of the WMS server experience.

=== Geotoolkit ===

* Referencing: fix inverse projection for fake spherical mercator.
* Referencing: accelerate raster reprojection.

* Coverage: Create a reader for GeoTiff images.

* Shapefile: reduce memory usage when leveraging a quad-tree index.
* Shapefile: reduce styling to one single pass when painting by symbol rather than by feature.
* Shapefile: reduce the reading of non-necessary parts of the files.
* Shapefile: fix handling of large (over 2GB) DBF attribute files.

* DataSource: Enable startup from a coverage mosaic, either a folder or a manager.

* Renderer: bypass rendering engine for single raster requests.
* Renderer: improve decimation algorithm for vector layers.
* Renderer: switch to OGC conformant 96dpi assumption rather than industry standard 72.
* Renderer: fix sld parsing errors to handle <ogc:Literal> or its absence.
* Renderer: optimize the colour model selected for multiple inputs.

=== Constellation-SDI ===

* Configuration: greatly enhance configurability of the server, with hot reload of data, styles and rendering configuration.

* Server: cache ServiceMetadata document for insanely slow data sources.
* Server: fix envelopes for data sources in ServiceMetadata document.

* Backend: fix multi-threading bug to use classes in a thread-safe manner.

* JEE output: enable direct writing of images into output stream.

* GUI: build a prototype interface.

== Performance Results ==

This section details the results of running the jmeter scripts against the Constellation-SDI WMS server.

'''Note:''' All values reported are in units of responses per second taken from the "Throughput" column of the 'summarizer.py' script. The values are those of the third pass, after the jmeter scripts have looped through the two warmup passes for the various thread counts, from one to sixty-four; we report only the measure from the last pass.

There are two sets of runs for two kinds of scripts: older scripts where all the requests are repeated in every pass and newer scripts where every request is different. It seems that the size of the data set we are using coupled with the number of requests just allows some servers to escape being disk bound in the older scripts with concomitant, order of magnitude jump in performance. In the general confusion, voting, ignoring vote results and whatever else, we ended up making both sets of runs.

=== Session 2010.09.03 (New, non-repeating scripts) ===

This was the first full run of Constellation-SDI using the jmeter scripts.

The runs were performed with the more recent jmeter design where all three runs use different requests so that the server is always asking for new files from disk.

For lack of time, a second run was only done for the two raster request sets; nonetheless, the numbers give us a ballpark estimate of variability between runs.

{| border="1" style="text-align:center"
! colspan ="9" | Raster 3rd Pass (New, non-repeating scripts)
|-
! rowspan ="2" | Threads !! colspan="4" | 25831 !! colspan="4" | 3857
|-
! Run 1 !! Run 2 !! Run 3 !! Run 4 !! Run 1 !! Run 2 !! Run 3 !! Run 4
|-
| 1 || 4.5 || 5.7 || --- || --- || 5.4 || 5.4 || --- || ---
|-
| 2 || 6.3 || 6.1 || --- || --- || 6.0 || 5.7 || --- || ---
|-
| 4 || 5.1 || 4.9 || --- || --- || 4.7 || 4.8 || --- || ---
|-
| 8 || 4.8 || 4.6 || --- || --- || 4.6 || 4.5 || --- || ---
|-
| 16 || 4.5 || 4.7 || --- || --- || 4.6 || 4.6 || --- || ---
|-
| 32 || 5.2 || 5.0 || --- || --- || 4.8 || 4.8 || --- || ---
|-
| 64 || 4.9 || 4.8 || --- || --- || 4.8 || 4.6 || --- || ---
|}

{| border="1" style="text-align:center"
! colspan ="9" | Vector 3rd Pass (New, non-repeating scripts)
|-
! rowspan ="2" | Threads !! colspan="4" | 4326 !! colspan="4" | 3857
|-
! Run 1 !! Run 2 !! Run 3 !! Run 4 !! Run 1 !! Run 2 !! Run 3 !! Run 4
|-
| 1 || 1.5 || --- || --- || --- || 1.5 || --- || --- || ---
|-
| 2 || 2.1 || --- || --- || --- || 2.1 || --- || --- || ---
|-
| 4 || 2.1 || --- || --- || --- || 2.3 || --- || --- || ---
|-
| 8 || 2.2 || --- || --- || --- || 2.3 || --- || --- || ---
|-
| 16 || 2.1 || --- || --- || --- || 2.2 || --- || --- || ---
|-
| 32 || 2.2 || --- || --- || --- || 2.3 || --- || --- || ---
|-
| 64 || 1.8 || --- || --- || --- || 1.9 || --- || --- || ---
|}

The processing power (8 CPUs) of the machine does not seem to have been stressed at any point in the test runs.

The numbers differ from the results obtained on local servers which had a more distinct separation between vector and raster results. Variability also seems high enough that several runs would be needed to discriminate between the various configurations, enough so that we probably need to tighten up the testing to get anything meaningful from numbers such as these.

=== Session 2010.09.03 afternoon (older, repeating scripts) ===

Repeating the earlier work, with the older scripts which may leave the file blocks in memory.

The first raster results, native CRS and reprojected, were performed with a mapserver running in the background so the test was repeated.

{| border="1" style="text-align:center"
! colspan ="9" | Raster 3rd Pass (older, repeating scripts)
|-
! rowspan ="2" | Threads !! colspan="4" | 25831 !! colspan="4" | 3857
|-
! Run 1 !! Run 2 !! Run 3 !! Run 4 !! Run 1 !! Run 2 !! Run 3 !! Run 4
|-
| 1 || 5.5 || 11.6 || --- || --- || 5.9 || 5.9 || --- || ---
|-
| 2 || 4.0 || 11.9 || --- || --- || 6.9 || 6.7 || --- || ---
|-
| 4 || 5.3 || 5.5 || --- || --- || 5.4 || 5.5 || --- || ---
|-
| 8 || 5.1 || 5.1 || --- || --- || 5.3 || 5.2 || --- || ---
|-
| 16 || 5.3 || 5.3 || --- || --- || 5.3 || 5.1 || --- || ---
|-
| 32 || 5.3 || 5.2 || --- || --- || 5.2 || 5.1 || --- || ---
|-
| 64 || 5.3 || 5.0 || --- || --- || 5.0 || 5.1 || --- || ---
|}

{| border="1" style="text-align:center"
! colspan ="9" | Vector 3rd Pass (older, repeating scripts)
|-
! rowspan ="2" | Threads !! colspan="4" | 4326 !! colspan="4" | 3857
|-
! Run 1 !! Run 2 !! Run 3 !! Run 4 !! Run 1 !! Run 2 !! Run 3 !! Run 4
|-
| 1 || 1.9 || --- || --- || --- || 1.8 || --- || --- || ---
|-
| 2 || 2.2 || --- || --- || --- || 2.1 || --- || --- || ---
|-
| 4 || 2.6 || --- || --- || --- || 2.7 || --- || --- || ---
|-
| 8 || 2.4 || --- || --- || --- || 2.5 || --- || --- || ---
|-
| 16 || 2.5 || --- || --- || --- || 2.6 || --- || --- || ---
|-
| 32 || 2.3 || --- || --- || --- || 2.4 || --- || --- || ---
|-
| 64 || 2.0 || --- || --- || --- || 2.0 || --- || --- || ---
|}

Not a dramatic change although these numbers are much less consistent than those generated with the older scripts. We can even burst up to well over 60 images per second for raster and 10 images per second for vector in some passes showing the danger of playing on this cusp for any meaningful results.

=== Session 2010.09.04 ===

This session was split into two parts.

The first part of the session aimed to look at the difference in performance when running with the correct configuration (which had mistakenly not been used in yesterday's session).

{| border="1" style="text-align:center"
! colspan ="9" | Raster 3rd Pass
|-
! rowspan ="2" | Threads !! colspan="4" | 25831 !! colspan="4" | 3857
|-
! Run 1 !! Run 2 !! Run 3 !! Run 4 !! Run 1 !! Run 2 !! Run 3 !! Run 4
|-
| 1 || 5.5 || 6.1 || --- || --- || 6.0 || --- || --- || ---
|-
| 2 || 6.4 || 6.1 || --- || --- || 6.8 || --- || --- || ---
|-
| 4 || 5.1 || 5.6 || --- || --- || 5.3 || --- || --- || ---
|-
| 8 || 6.9 || 5.4 || --- || --- || 5.3 || --- || --- || ---
|-
| 16 || 5.7 || 5.4 || --- || --- || 5.2 || --- || --- || ---
|-
| 32 || 5.3 || 5.3 || --- || --- || 5.4 || --- || --- || ---
|-
| 64 || 5.3 || 5.0 || --- || --- || 5.1 || --- || --- || ---
|}

The results are slightly better due to their consistency but essentially in the same ballpark.

The second part of the session set out to look at performance not limited by the IO bottleneck.

'''''Note that this is merely an academic exercise since for any non-trivial dataset, the size of data on disk will be so much larger than the size of available memory that these numbers will never be achieved.'''''

In order to generate this behaviour, the session involved a bunch of runs with the same requests as with the earlier session but with the scripts cut up and restructured so that the data would already have been read by the time the requests are made. The approach yielded somewhat stable numbers with a variability between runs of around 10%.

The results reported are the last run performed for any thread group. The runs with 32 threads and 64 threads were done with three single passes to save time and to ensure the requests would not outstrip main memory.

{| border="1" style="text-align:center"
! colspan ="9" | Raster 3rd Pass
|-
! rowspan ="2" | Threads !! colspan="4" | 25831 !! colspan="4" | 3857
|-
! Results !! ----- !! ----- !! ----- !! Results !! ----- !! ----- !! -----
|-
| 1 || 13.2 || --- || --- || --- || 11.6 || --- || --- || ---
|-
| 2 || 21.6 || --- || --- || --- || 19.6 || --- || --- || ---
|-
| 4 || 32.8 || --- || --- || --- || 40.1 || --- || --- || ---
|-
| 8 || 34.8 || --- || --- || --- || 30.1 || --- || --- || ---
|-
| 16 || 34.9 || --- || --- || --- || 34.1 || --- || --- || ---
|-
| 32 || 35.7 || --- || --- || --- || 33.7 || --- || --- || ---
|-
| 64 || 35.3 || --- || --- || --- || 32.4 || --- || --- || ---
|}

Clearly this is different behaviour, and only occurs after repeated requests for the same images so is not realistic in any way. Because the I/O throughput of the machine was not monitored while the test was running, we cannot be sure either that this is really peak, all in memory performance.

The result serves best as a reminder that benchmarks need to be setup carefully in order to measure the behaviour which one wants to measure since lurking nearby are order of magnitude changes in performance.

=== Session NEXT ===

''This is a placeholder and template for future runs''

{| border="1" style="text-align:center"
! colspan ="9" | Raster 3rd Pass
|-
! rowspan ="2" | Threads !! colspan="4" | 25831 !! colspan="4" | 3857
|-
! Run 1 !! Run 2 !! Run 3 !! Run 4 !! Run 1 !! Run 2 !! Run 3 !! Run 4
|-
| 1 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 2 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 4 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 8 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 16 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 32 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 64 || --- || --- || --- || --- || --- || --- || --- || ---
|}

{| border="1" style="text-align:center"
! colspan ="9" | Vector 3rd Pass
|-
! rowspan ="2" | Threads !! colspan="4" | 4326 !! colspan="4" | 3857
|-
! Run 1 !! Run 2 !! Run 3 !! Run 4 !! Run 1 !! Run 2 !! Run 3 !! Run 4
|-
| 1 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 2 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 4 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 8 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 16 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 32 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 64 || --- || --- || --- || --- || --- || --- || --- || ---
|}

Benchmarking 2010/Constellation-SDI

2010-09-04T12:26:17Z

Wiki-Acuster: Added the first part of the Saturday testing session.

This page describes the experience of the Constellation-SDI team during the FOSS4G 2010 Benchmarking effort.

== Benchmark design ==

We expended a great deal of effort attempting to understand how a benchmarking effort could be designed properly.

The 2009 and 2010 efforts were undertaken in the naive belief that one simply sets up different servers on the same data and makes requests of the servers to compare response times. Belatedly, the 2010 effort is demonstrating that a proper benchmark is more complex, since the data might be in a format useful for a certain class of use cases but meaningless for another scale of usage, the testing can easily be hardware bound limiting useful comparison between servers, servers can be set up to be doing very different work especially in 'best effort'/anything goes configurations, and results can be compared only in superficial ways or in very narrow types of requests. In order to tackle these issues rather than merely pretend they were not serious, we examined what it would take to develop a useful benchmarking protocol, either to stress all the functionality of one particular server or to compare the performance and abilities of various, arbitrary WMS servers.

Developing a WMS benchmarking design which provides useful, comparative metrics of server performance is exceedingly hard. In a recent presentation at the Java Language Summit, Joshua Bloch presented a talk entitled [http://wiki.jvmlangsummit.com/images/1/1d/PerformanceAnxiety2010.pdf ''Performance Anxiety''] which describes the impossibility of developing performant software from first principles in any language due to the enhancements of compilation and machine instruction re-ordering, the necessity of testing to obtain concrete results, and the difficulty of developing proper, statistically rigourous testing metrics.

Since these issues were apparent to us even before this effort, we have been developing tools, benchmark designs and analytic methodologies to test the Constellation-SDI server. This work has been greatly extended during the FOSS4G 2010 benchmarking effort and expanded to consider how to test different WMS servers, possibly built for different uses.

Unfortunately, there is still much distance to go before achieving a solid benchmarking suite. This work will undoubtedly be continued in the future, most likely within the framework of Open Geospatial Consortium (OGC) testing.

== Enhancements ==

This section describes enhancements due to the work during the benchmarking 2010 effort, including improved understanding and workflow by the Constellation-SDI team and ameliorations to the code bases of the [http://www.geotoolkit.org/ Geotoolkit.org] library and to the [http://www.constellation-sdi.org Constellation-SDI] server itself.

=== Benchmarking ===

* Investigate numerous issues with jmeter.
* Design simpler scripts.
* Examine different configurations to stress different aspects of the WMS server experience.

=== Geotoolkit ===

* Referencing: fix inverse projection for fake spherical mercator.
* Referencing: accelerate raster reprojection.

* Coverage: Create a reader for GeoTiff images.

* Shapefile: reduce memory usage when leveraging a quad-tree index.
* Shapefile: reduce styling to one single pass when painting by symbol rather than by feature.
* Shapefile: reduce the reading of non-necessary parts of the files.

* DataSource: Enable startup from a coverage mosaic, either a folder or a manager.

* Renderer: bypass rendering engine for single raster requests.
* Renderer: improve decimation algorithm for vector layers.
* Renderer: switch to OGC conformant 96dpi assumption rather than industry standard 72.
* Renderer: fix sld parsing errors to handle <ogc:Literal> or its absence.
* Renderer: optimize the colour model selected for multiple inputs.

=== Constellation-SDI ===

* Configuration: greatly enhance configurability of the server, with hot reload of data, styles and rendering configuration.

* Server: cache ServiceMetadata document for insanely slow data sources.
* Server: fix envelopes for data sources in ServiceMetadata document.

* Backend: fix multi-threading bug to use classes in a thread-safe manner.

* JEE output: enable direct writing of images into output stream.

* GUI: build a prototype interface.

== Performance Results ==

This section details the results of running the jmeter scripts against the Constellation-SDI WMS server.

'''Note:''' All values reported are in units of responses per second taken from the "Throughput" column of the 'summarizer.py' script. The values are those of the third pass, after the jmeter scripts have looped through the two warmup passes for the various thread counts, from one to sixty-four; we report only the measure from the last pass.

There are two sets of runs for two kinds of scripts: older scripts where all the requests are repeated in every pass and newer scripts where every request is different. It seems that the size of the data set we are using coupled with the number of requests just allows some servers to escape being disk bound in the older scripts with concomitant, order of magnitude jump in performance. In the general confusion, voting, ignoring vote results and whatever else, we ended up making both sets of runs.

=== Session 2010.09.03 (New, non-repeating scripts) ===

This was the first full run of Constellation-SDI using the jmeter scripts.

The runs were performed with the more recent jmeter design where all three runs use different requests so that the server is always asking for new files from disk.

For lack of time, a second run was only done for the two raster request sets; nonetheless, the numbers give us a ballpark estimate of variability between runs.

{| border="1" style="text-align:center"
! colspan ="9" | Raster 3rd Pass (New, non-repeating scripts)
|-
! rowspan ="2" | Threads !! colspan="4" | 25831 !! colspan="4" | 3857
|-
! Run 1 !! Run 2 !! Run 3 !! Run 4 !! Run 1 !! Run 2 !! Run 3 !! Run 4
|-
| 1 || 4.5 || 5.7 || --- || --- || 5.4 || 5.4 || --- || ---
|-
| 2 || 6.3 || 6.1 || --- || --- || 6.0 || 5.7 || --- || ---
|-
| 4 || 5.1 || 4.9 || --- || --- || 4.7 || 4.8 || --- || ---
|-
| 8 || 4.8 || 4.6 || --- || --- || 4.6 || 4.5 || --- || ---
|-
| 16 || 4.5 || 4.7 || --- || --- || 4.6 || 4.6 || --- || ---
|-
| 32 || 5.2 || 5.0 || --- || --- || 4.8 || 4.8 || --- || ---
|-
| 64 || 4.9 || 4.8 || --- || --- || 4.8 || 4.6 || --- || ---
|}

{| border="1" style="text-align:center"
! colspan ="9" | Vector 3rd Pass (New, non-repeating scripts)
|-
! rowspan ="2" | Threads !! colspan="4" | 4326 !! colspan="4" | 3857
|-
! Run 1 !! Run 2 !! Run 3 !! Run 4 !! Run 1 !! Run 2 !! Run 3 !! Run 4
|-
| 1 || 1.5 || --- || --- || --- || 1.5 || --- || --- || ---
|-
| 2 || 2.1 || --- || --- || --- || 2.1 || --- || --- || ---
|-
| 4 || 2.1 || --- || --- || --- || 2.3 || --- || --- || ---
|-
| 8 || 2.2 || --- || --- || --- || 2.3 || --- || --- || ---
|-
| 16 || 2.1 || --- || --- || --- || 2.2 || --- || --- || ---
|-
| 32 || 2.2 || --- || --- || --- || 2.3 || --- || --- || ---
|-
| 64 || 1.8 || --- || --- || --- || 1.9 || --- || --- || ---
|}

The processing power (8 CPUs) of the machine does not seem to have been stressed at any point in the test runs.

The numbers differ from the results obtained on local servers which had a more distinct separation between vector and raster results. Variability also seems high enough that several runs would be needed to discriminate between the various configurations, enough so that we probably need to tighten up the testing to get anything meaningful from numbers such as these.

=== Session 2010.09.03 afternoon (older, repeating scripts) ===

Repeating the earlier work, with the older scripts which may leave the file blocks in memory.

The first raster results, native CRS and reprojected, were performed with a mapserver running in the background so the test was repeated.

{| border="1" style="text-align:center"
! colspan ="9" | Raster 3rd Pass (older, repeating scripts)
|-
! rowspan ="2" | Threads !! colspan="4" | 25831 !! colspan="4" | 3857
|-
! Run 1 !! Run 2 !! Run 3 !! Run 4 !! Run 1 !! Run 2 !! Run 3 !! Run 4
|-
| 1 || 5.5 || 11.6 || --- || --- || 5.9 || 5.9 || --- || ---
|-
| 2 || 4.0 || 11.9 || --- || --- || 6.9 || 6.7 || --- || ---
|-
| 4 || 5.3 || 5.5 || --- || --- || 5.4 || 5.5 || --- || ---
|-
| 8 || 5.1 || 5.1 || --- || --- || 5.3 || 5.2 || --- || ---
|-
| 16 || 5.3 || 5.3 || --- || --- || 5.3 || 5.1 || --- || ---
|-
| 32 || 5.3 || 5.2 || --- || --- || 5.2 || 5.1 || --- || ---
|-
| 64 || 5.3 || 5.0 || --- || --- || 5.0 || 5.1 || --- || ---
|}

{| border="1" style="text-align:center"
! colspan ="9" | Vector 3rd Pass (older, repeating scripts)
|-
! rowspan ="2" | Threads !! colspan="4" | 4326 !! colspan="4" | 3857
|-
! Run 1 !! Run 2 !! Run 3 !! Run 4 !! Run 1 !! Run 2 !! Run 3 !! Run 4
|-
| 1 || 1.9 || --- || --- || --- || 1.8 || --- || --- || ---
|-
| 2 || 2.2 || --- || --- || --- || 2.1 || --- || --- || ---
|-
| 4 || 2.6 || --- || --- || --- || 2.7 || --- || --- || ---
|-
| 8 || 2.4 || --- || --- || --- || 2.5 || --- || --- || ---
|-
| 16 || 2.5 || --- || --- || --- || 2.6 || --- || --- || ---
|-
| 32 || 2.3 || --- || --- || --- || 2.4 || --- || --- || ---
|-
| 64 || 2.0 || --- || --- || --- || 2.0 || --- || --- || ---
|}

Not a dramatic change although these numbers are much less consistent than those generated with the older scripts. We can even burst up to well over 60 images per second for raster and 10 images per second for vector in some passes showing the danger of playing on this cusp for any meaningful results.

=== Session 2010.09.04 ===

This session was split into two parts.

The first part of the session aimed to look at the difference in performance when running with the correct configuration (which had mistakenly not been used in yesterday's session).

{| border="1" style="text-align:center"
! colspan ="9" | Raster 3rd Pass
|-
! rowspan ="2" | Threads !! colspan="4" | 25831 !! colspan="4" | 3857
|-
! Run 1 !! Run 2 !! Run 3 !! Run 4 !! Run 1 !! Run 2 !! Run 3 !! Run 4
|-
| 1 || 5.5 || 6.1 || --- || --- || 6.0 || --- || --- || ---
|-
| 2 || 6.4 || 6.1 || --- || --- || 6.8 || --- || --- || ---
|-
| 4 || 5.1 || 5.6 || --- || --- || 5.3 || --- || --- || ---
|-
| 8 || 6.9 || 5.4 || --- || --- || 5.3 || --- || --- || ---
|-
| 16 || 5.7 || 5.4 || --- || --- || 5.2 || --- || --- || ---
|-
| 32 || 5.3 || 5.3 || --- || --- || 5.4 || --- || --- || ---
|-
| 64 || 5.3 || 5.0 || --- || --- || 5.1 || --- || --- || ---
|}

The results are slightly better due to their consistency but essentially in the same ballpark.

The second part of the session set out to look at performance not limited by the IO bottleneck.

'''''Note that this is merely an academic exercise since for any non-trivial dataset, the size of data on disk will be so much larger than the size of available memory that these numbers will never be achieved.'''''

In order to generate this behaviour, the session involved a bunch of runs with the same requests as with the earlier session but with the scripts cut up and restructured so that the data would already have been read by the time the requests are made. The approach yielded somewhat stable numbers with a variability between runs of around 10%.

The results reported are the last run performed for any thread group. The runs with 32 threads and 64 threads were done with three single passes to save time and to ensure the requests would not outstrip main memory.

{| border="1" style="text-align:center"
! colspan ="9" | Raster 3rd Pass
|-
! rowspan ="2" | Threads !! colspan="4" | 25831 !! colspan="4" | 3857
|-
! Results !! ----- !! ----- !! ----- !! Results !! ----- !! ----- !! -----
|-
| 1 || 13.2 || --- || --- || --- || 11.6 || --- || --- || ---
|-
| 2 || 21.6 || --- || --- || --- || 19.6 || --- || --- || ---
|-
| 4 || 32.8 || --- || --- || --- || 40.1 || --- || --- || ---
|-
| 8 || 34.8 || --- || --- || --- || 30.1 || --- || --- || ---
|-
| 16 || 34.9 || --- || --- || --- || 34.1 || --- || --- || ---
|-
| 32 || 35.7 || --- || --- || --- || 33.7 || --- || --- || ---
|-
| 64 || 35.3 || --- || --- || --- || 32.4 || --- || --- || ---
|}

Clearly this is different behaviour, and only occurs after repeated requests for the same images so is not realistic in any way. Because the I/O throughput of the machine was not monitored while the test was running, we cannot be sure either that this is really peak, all in memory performance.

The result serves best as a reminder that benchmarks need to be setup carefully in order to measure the behaviour which one wants to measure since lurking nearby are order of magnitude changes in performance.

=== Session NEXT ===

''This is a placeholder and template for future runs''

{| border="1" style="text-align:center"
! colspan ="9" | Raster 3rd Pass
|-
! rowspan ="2" | Threads !! colspan="4" | 25831 !! colspan="4" | 3857
|-
! Run 1 !! Run 2 !! Run 3 !! Run 4 !! Run 1 !! Run 2 !! Run 3 !! Run 4
|-
| 1 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 2 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 4 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 8 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 16 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 32 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 64 || --- || --- || --- || --- || --- || --- || --- || ---
|}

{| border="1" style="text-align:center"
! colspan ="9" | Vector 3rd Pass
|-
! rowspan ="2" | Threads !! colspan="4" | 4326 !! colspan="4" | 3857
|-
! Run 1 !! Run 2 !! Run 3 !! Run 4 !! Run 1 !! Run 2 !! Run 3 !! Run 4
|-
| 1 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 2 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 4 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 8 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 16 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 32 || --- || --- || --- || --- || --- || --- || --- || ---
|-
| 64 || --- || --- || --- || --- || --- || --- || --- || ---
|}