[OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
OSGeo Community, Currently, voting OGC members are to decide whether to accept the GeoServices REST API as an OGC standard. This is already a contentious issue, with 13 votes for, and 10 votes against, 72 outstanding votes, with voting halted temporally, being reopened again in a few days, and closing 2 weeks after that. [1] I'm wanting to hear whether people in the OSGeo community have strong opinions regarding this proposed standard, and whether we as a collective OSGeo community should make statements to the OGC, and voting OGC members, stressing our thoughts. If there is sufficient interest, I'll raise this issue with the OSGeo Board, with the intent of drafting a statement on behalf of OSGeo. As background: * The API was initially developed by Esri and implemented on the ArcGIS for Server platform. [2] * The proposed GeoServices REST API specification overlaps with most OGC standards already deployed, including: WMS, WMTS, WCS, WFS, SE/SLD, CS/W. This effectively means that for most use cases covered by the GeoServices REST API, applications would now have two standards to support. Also, spatial infrastructure programs will be impacted, as OGC compliance won't necessarily equate to interoperability. * Most (all?) current OGC web service standards to date have an Open Source reference implementation, which was often (always?) part funded by OGC testbeds, and open source implementations were tested against proprietary implementations during OGC testbeds. As far as I'm aware, there has been very little up-take from the Open Source community of the GeoServices REST API, and I'm unaware of any testing of non-ESRI applications during OGC testbeds. (Someone may be able to correct me here). [1] https://portal.opengeospatial.org/?m=projectsa=viewproject_id=82tab=5subtab=0 (OGC member login required. Votes counted as at 4 May 2013) [2] http://www.opengeospatial.org/standards/requests/89 -- Cameron Shorter Geospatial Solutions Manager Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 Think Globally, Fix Locally Geospatial Solutions enhanced with Open Standards and Open Source http://www.lisasoft.com ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
Hi cameron I think ogc is stand as standard body which will home as geoservices Yes, there are several overlap I prefer esri to certified his product withnogc rather make new standarsd in ogc That is dangerous to community On May 4, 2013 5:46 PM, Cameron Shorter cameron.shor...@gmail.com wrote: OSGeo Community, Currently, voting OGC members are to decide whether to accept the GeoServices REST API as an OGC standard. This is already a contentious issue, with 13 votes for, and 10 votes against, 72 outstanding votes, with voting halted temporally, being reopened again in a few days, and closing 2 weeks after that. [1] I'm wanting to hear whether people in the OSGeo community have strong opinions regarding this proposed standard, and whether we as a collective OSGeo community should make statements to the OGC, and voting OGC members, stressing our thoughts. If there is sufficient interest, I'll raise this issue with the OSGeo Board, with the intent of drafting a statement on behalf of OSGeo. As background: * The API was initially developed by Esri and implemented on the ArcGIS for Server platform. [2] * The proposed GeoServices REST API specification overlaps with most OGC standards already deployed, including: WMS, WMTS, WCS, WFS, SE/SLD, CS/W. This effectively means that for most use cases covered by the GeoServices REST API, applications would now have two standards to support. Also, spatial infrastructure programs will be impacted, as OGC compliance won't necessarily equate to interoperability. * Most (all?) current OGC web service standards to date have an Open Source reference implementation, which was often (always?) part funded by OGC testbeds, and open source implementations were tested against proprietary implementations during OGC testbeds. As far as I'm aware, there has been very little up-take from the Open Source community of the GeoServices REST API, and I'm unaware of any testing of non-ESRI applications during OGC testbeds. (Someone may be able to correct me here). [1] https://portal.opengeospatial.**org/?m=projectsa=view** project_id=82tab=5subtab=0https://portal.opengeospatial.org/?m=projectsa=viewproject_id=82tab=5subtab=0 (OGC member login required. Votes counted as at 4 May 2013) [2] http://www.opengeospatial.org/**standards/requests/89http://www.opengeospatial.org/standards/requests/89 -- Cameron Shorter Geospatial Solutions Manager Tel: +61 (0)2 8570 5050 Mob: +61 (0)419 142 254 Think Globally, Fix Locally Geospatial Solutions enhanced with Open Standards and Open Source http://www.lisasoft.com __**_ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/**mailman/listinfo/discusshttp://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
On Sat, May 4, 2013 at 11:46 AM, Cameron Shorter cameron.shor...@gmail.com wrote: I'm wanting to hear whether people in the OSGeo community have strong opinions regarding this proposed standard, and whether we as a collective OSGeo community should make statements to the OGC, and voting OGC members, stressing our thoughts. My current concern is that the standards documents are in a bunch of Microsoft Word files. And a bunch of Microsoft Word files that *crash* my current version of OpenOffice Oh the comedy of open standards being written using non-open file formats[1] The ironic comment of standards are great - lets have more of them possibly applies here. In terms of open source implementations, the google search geoservices rest api github doesn't find much, so I suspect the open source community is happy with its web APIs already. These guys: https://github.com/WSDOT-GIS/Traveler-Info-GeoServices-REST appear to be implementing a GeoServices REST endpoint for their system, maybe they'd be willing to refactor their code out and develop it as a reference server implementation? But oh dear it seems to be written in C#. I'm not sure what the term 'reference implementation' means here. Any difference in behaviour between an implementation and the spec is a bug with the implementation, yes? For that I don't think it matters if the reference implementation is open source or a black box - that's irrelevant to its compliance with the standard. However, a freely-available implementation does make it easier (and in some cases, possible) to write code that works practically. I wouldn't like to write a GeoServices client without a server to test it against. Without it my option is to check my client request is correct by comparing it with the standards document (in that unreadable Word document). Imagine if the authors of the first web browsers hadn't had http servers to actually test against? The advantages of an open source reference implementation are also the usual advantages of open source that we've been banging on about for years. Mismatches between open source implementations and standards docs can be fixed in minutes and released, and users don't have to wait six months for the next product update release, for example. Is there an open-source reference implementation of code to work with every aspect of the KML file standard? The situation seems analagous - a proprietary standard pushed to OGC and opened up. Barry [1] yeah this is probably wrong and MS got their file formats certified 'open' somehow... blah blah court case blah blah ISO voting blah blah ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
Dear Cameron, all, There is indeed a massive conflict at the OGC related to this proposed standard and it may be useful to inform this list about that conflict and the process. However, I am unsure how expanding the *discussion* here helps. The proposed standard aims to document a series of web services and a JSON based data exchange format. The standard comes in eight parts 12-054r2 GeoServices REST API - Part 1: Core 12-055r2 GeoServices REST API - Part 2: Catalog 12-056r2 GeoServices REST API - Part 3: Map Service 12-057r2 GeoServices REST API - Part 4: Feature Service 12-058r2 GeoServices REST API - Part 5: Geometry Service 12-059r2 GeoServices REST API - Part 6: Image Service 12-060r2 GeoServices REST API - Part 7: Geoprocessing Service 12-061r2 GeoServices REST API - Part 8: Geocoding Service and there are also 12-068r2 GeoServices REST API - JSON Schemas and Examples The documents describe the functioning of a set of web services, developed originally by ESRI, and the JSON format for many objects, also defined by ESRI, and used by those services. The OGC request for comments (now closed) is here: http://www.opengeospatial.org/standards/requests/89 with each of the documents. Note that Cameron was either unclear or incorrect in his presentation of where the standard now stands. * The document was released for public comment. (see above) * A response to all the comments was issued. (however incomplete) * The document was then released for a vote. * The vote was suspended because two 'no' votes were heard. * A response was issued to the 'no' votes. * The vote was resumed * The vote was (re) suspended because two additional 'no' votes were heard, with new arguments. = the vote is current suspended awaiting (1) a response to the new reasons, and (2) a decision of what to do next by the leadership of the OGC technical committee (where all this work happens), since we have not yet faced such lack of consensus. The proposed standard has been controversial from the start at the OGC. The controversy, as best as I can tell, centers on the following issues: * no backwards incompatible changes were allowed, * no work was done to integrate the proposed services with existing OGC services (W*S, ...), * the only implementations are by ESRI and its partners, * the name of the standard and services are not accurate or distinct. Banning backwards incompatible changes is controversial both because it blocked collaboration at the OGC (which essentially had to approve the ESRI implementation as is) and because it prevented things like using GeoJSON where appropriate. Also, going forwards, backwards compatibility will have to be maintained giving the existing implementations (i.e. ESRI's) a huge advantage in defining extensions (ESRI already has a number in the pipeline). The lack of integration with existing services is controversial both because they made no effort to work with the existing working groups and because it splits the work of the OGC into competing efforts. There is no clear path forwards towards harmonization despite the fact that most groups working on OGC Services are tackling issues in the same area (simple services, JSON exchange format, REST design). The dominance of ESRI is controversial both because the working mode lacked any collaborative spirit and, perhaps most critically, because this is seen as a way through which ESRI can bring its own service onto an equal footing with the current, public OGC standards in the government procurement game. Governments are shifting towards requiring that all spatial software conform with published, open standards; the proposed standard, if adopted, would allow ESRI to push its own software as also an Open Standard and compete on an unequal footing with implementations of the software being worked on by everyone else. The name of the standard 'GeoServices REST API' and the services are controversial for many reasons. The 'GeoServices' moniker is non-descript (many OGC standards are for geospatial services) and matches the current ESRI marketing terminology. 'REST' is a buzzword and implies a lot of design work which has not been done (and is happening elsewhere at the OGC); furthermore, if REST is about the design of a service's behaviour (that the service acts based on the transfer of representations of resources), then the word does not relate to an 'API'. Finally, the 'API' word does not really describe the standard which is describing a number of services and data exchange formats. The names of each service, e.g. either 'Map Service' or 'GeoServices Map Service' is problematic: how do we make sure that people know the difference between the 'OGC Web Map Service' and the 'OGC GeoService Map Service' ? However, despite these criticisms,
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
Il 04/05/2013 18:43, Adrian Custer ha scritto: Which brings us to OSGeo and what useful contribution it could make to the debate. Simply rehashing the issues above is not going to be useful to anyone. If new ideas arise, or a large, common position emerges on the issue, I'd be glad to inject them into the OGC discussion. I suspect there is at least a week before voting resumes, although the rules going forwards are not yet clear. Adrian, your overview is very helpful. From where I stand, there are three reasons to push for a no to the proposed standard, all touched in your or Cameron's message: 1. disrespect for an existing, widespread, appreciated standard: GeoJSON 2. no open source reference implementation 3. vote was already suspended multiple times, showing a lack of agreement about this standard Points 1 and 2 are part of the OSGeo mission IMHO. Thank you steko -- Stefano Costa http://steko.iosa.it/ ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
Hey Barry, There is no useful concept of a 'reference implementation' at the OGC. The things the OGC calls 'reference implementation' are actually example testing implementations. The word was incorrectly adopted by the testing group (pushed by those with commercial concerns). The testing group now wants to have multiple 'reference implementations' showing they are not really a 'reference' in the common understood meaning. I am trying to get the testers to change the terminology to avoid the semantic conflict with the general meaning of 'reference implementation.' Critically, none of the implementations were vetted by the groups defining the actual standards documents so there is little relation between the implementation and the standard. It therefore makes little sense to think of 'reference implementations' at the OGC. As far as GeoServices REST, the default reference implementations are ESRI's since the document is merely defining how those implementations work. ~adrian On 5/4/13 1:27 PM, Barry Rowlingson wrote: On Sat, May 4, 2013 at 11:46 AM, Cameron Shorter cameron.shor...@gmail.com wrote: I'm wanting to hear whether people in the OSGeo community have strong opinions regarding this proposed standard, and whether we as a collective OSGeo community should make statements to the OGC, and voting OGC members, stressing our thoughts. My current concern is that the standards documents are in a bunch of Microsoft Word files. And a bunch of Microsoft Word files that *crash* my current version of OpenOffice Oh the comedy of open standards being written using non-open file formats[1] The ironic comment of standards are great - lets have more of them possibly applies here. In terms of open source implementations, the google search geoservices rest api github doesn't find much, so I suspect the open source community is happy with its web APIs already. These guys: https://github.com/WSDOT-GIS/Traveler-Info-GeoServices-REST appear to be implementing a GeoServices REST endpoint for their system, maybe they'd be willing to refactor their code out and develop it as a reference server implementation? But oh dear it seems to be written in C#. I'm not sure what the term 'reference implementation' means here. Any difference in behaviour between an implementation and the spec is a bug with the implementation, yes? For that I don't think it matters if the reference implementation is open source or a black box - that's irrelevant to its compliance with the standard. However, a freely-available implementation does make it easier (and in some cases, possible) to write code that works practically. I wouldn't like to write a GeoServices client without a server to test it against. Without it my option is to check my client request is correct by comparing it with the standards document (in that unreadable Word document). Imagine if the authors of the first web browsers hadn't had http servers to actually test against? The advantages of an open source reference implementation are also the usual advantages of open source that we've been banging on about for years. Mismatches between open source implementations and standards docs can be fixed in minutes and released, and users don't have to wait six months for the next product update release, for example. Is there an open-source reference implementation of code to work with every aspect of the KML file standard? The situation seems analagous - a proprietary standard pushed to OGC and opened up. Barry [1] yeah this is probably wrong and MS got their file formats certified 'open' somehow... blah blah court case blah blah ISO voting blah blah ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
Is there an open-source reference implementation of code to work with every aspect of the KML file standard? The situation seems analagous - a proprietary standard pushed to OGC and opened up. https://code.google.com/p/libkml/ ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
Note that Cameron was either unclear or incorrect in his presentation of where the standard now stands. * The document was released for public comment. (see above) * A response to all the comments was issued. (however incomplete) Adrian, Do you have by chance a link to the response to comments ? I did write comments on the documents during the public comment period, but didn't remember seeing any response posted on the OGC list where I posted my comments... Best regards, Even ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
On Sat, May 4, 2013 at 9:43 AM, Adrian Custer acus...@gmail.com wrote: The dominance of ESRI is controversial both because the working mode lacked any collaborative spirit and, perhaps most critically, because this is seen as a way through which ESRI can bring its own service onto an equal footing with the current, public OGC standards in the government procurement game. Governments are shifting towards requiring that all spatial software conform with published, open standards; the proposed standard, if adopted, would allow ESRI to push its own software as also an Open Standard and compete on an unequal footing with implementations of the software being worked on by everyone else. - To elaborate on the unequal footing phrase above: One additional aspect of the government side of this equation is that for several years there has been a trend (similar to Microsoft products) in getting the ESRI architecture adopted as a GIS software standard within government IT enterprise contexts. This then requires agencies to transition to use of the ESRI platform exclusively for geospatial work. Projecting into the future, if there were 2 competing OGC service types and ESRI were to drop support for the older W*S family of OGC services (or merely push support for them out of the core packages and into an expensive interoperability add-on), this would place many agencies in a situation of only being able to serve the newer standards, effectively killing the older standards within those contexts... ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
Adrian, Thankyou, I was hoping that someone such as your self with insights into the standard would explain the details. You email has been a great help. I'm also hoping that someone will provide a more detailed comparison of the similarities / differences, to help the rest of the community understand what is happening. On 05/05/13 02:43, Adrian Custer wrote: Dear Cameron, all, There is indeed a massive conflict at the OGC related to this proposed standard and it may be useful to inform this list about that conflict and the process. However, I am unsure how expanding the *discussion* here helps. The proposed standard aims to document a series of web services and a JSON based data exchange format. The standard comes in eight parts 12-054r2 GeoServices REST API - Part 1: Core 12-055r2 GeoServices REST API - Part 2: Catalog 12-056r2 GeoServices REST API - Part 3: Map Service 12-057r2 GeoServices REST API - Part 4: Feature Service 12-058r2 GeoServices REST API - Part 5: Geometry Service 12-059r2 GeoServices REST API - Part 6: Image Service 12-060r2 GeoServices REST API - Part 7: Geoprocessing Service 12-061r2 GeoServices REST API - Part 8: Geocoding Service and there are also 12-068r2 GeoServices REST API - JSON Schemas and Examples The documents describe the functioning of a set of web services, developed originally by ESRI, and the JSON format for many objects, also defined by ESRI, and used by those services. The OGC request for comments (now closed) is here: http://www.opengeospatial.org/standards/requests/89 with each of the documents. Note that Cameron was either unclear or incorrect in his presentation of where the standard now stands. * The document was released for public comment. (see above) * A response to all the comments was issued. (however incomplete) * The document was then released for a vote. * The vote was suspended because two 'no' votes were heard. * A response was issued to the 'no' votes. * The vote was resumed * The vote was (re) suspended because two additional 'no' votes were heard, with new arguments. = the vote is current suspended awaiting (1) a response to the new reasons, and (2) a decision of what to do next by the leadership of the OGC technical committee (where all this work happens), since we have not yet faced such lack of consensus. The proposed standard has been controversial from the start at the OGC. The controversy, as best as I can tell, centers on the following issues: * no backwards incompatible changes were allowed, * no work was done to integrate the proposed services with existing OGC services (W*S, ...), * the only implementations are by ESRI and its partners, * the name of the standard and services are not accurate or distinct. Banning backwards incompatible changes is controversial both because it blocked collaboration at the OGC (which essentially had to approve the ESRI implementation as is) and because it prevented things like using GeoJSON where appropriate. Also, going forwards, backwards compatibility will have to be maintained giving the existing implementations (i.e. ESRI's) a huge advantage in defining extensions (ESRI already has a number in the pipeline). The lack of integration with existing services is controversial both because they made no effort to work with the existing working groups and because it splits the work of the OGC into competing efforts. There is no clear path forwards towards harmonization despite the fact that most groups working on OGC Services are tackling issues in the same area (simple services, JSON exchange format, REST design). The dominance of ESRI is controversial both because the working mode lacked any collaborative spirit and, perhaps most critically, because this is seen as a way through which ESRI can bring its own service onto an equal footing with the current, public OGC standards in the government procurement game. Governments are shifting towards requiring that all spatial software conform with published, open standards; the proposed standard, if adopted, would allow ESRI to push its own software as also an Open Standard and compete on an unequal footing with implementations of the software being worked on by everyone else. The name of the standard 'GeoServices REST API' and the services are controversial for many reasons. The 'GeoServices' moniker is non-descript (many OGC standards are for geospatial services) and matches the current ESRI marketing terminology. 'REST' is a buzzword and implies a lot of design work which has not been done (and is happening elsewhere at the OGC); furthermore, if REST is about the design of a service's behaviour (that the service acts based on the transfer of representations of resources), then the word does not relate to an 'API'. Finally, the 'API' word does not really
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
On 5/4/13 6:06 PM, Jody Garnett wrote: Thanks for the background Adrian, do we know of any other parties with implementation plans? -- Jody Garnett The known implementations are listed in the document responding to the 'no' vote. I won't list them here 'till I hear back on the status of these documents as public ( f*^(ing Imaginary Property Rules that won't die). However, you'll be glad to know that GDAL is listed as an implementation in the Processing GeoServices JSON since it can read the JSON file returned from one of the services! ~adrian ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
On 5/4/13 6:21 PM, Cameron Shorter wrote: Adrian, Thankyou, I was hoping that someone such as your self with insights into the standard would explain the details. You email has been a great help. Cheers. I'm also hoping that someone will provide a more detailed comparison of the similarities / differences, to help the rest of the community understand what is happening. I have not taken much detailed interest in these services ever since it became clear that they had no interest in working with the WMS folk and that nothing could be changed to improve the standard. (They couldn't even fix dates to be in the unambiguous ISO 8609 format -MM-DD since that would break 'backwards compatibility'!) My understanding is that these services are built on what I call the Flat Feature Model which are Features with single geometries made up of 2D, linear structures (points, lines, or polygons) and a list of primitive value attributes (the shapefile data model). (Simple Features, it turns out, are not so simple; they can only have a single geometry but that geometry can be multidimensional and complex while the attributes can be arbitrarily complex and in various namespaces. So 'Flat Features' are what I used to think 'Simple Features' were.) There is surely a need for very simple geospatial services which are limited to the Flat Feature Model. That is why we have all been working on rewriting the W*S standards in modular form to allow for very simple implementations while also enabling more complex implementations, experiments, and easier fixes. The ESRI effort, had it been designed to help users, could easily have plugged into the efforts going on in the various W*S groups. Instead, it has so far been a complete drain on my time. ~adrian ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
Re: [OSGeo-Discuss] Would you be concerned if the GeoServices REST API became an OGC standard?
TC Haddad wrote: - To elaborate on the unequal footing phrase above: One additional aspect of the government side of this equation is that for several years there has been a trend (similar to Microsoft products) in getting the ESRI architecture adopted as a GIS software standard within government IT enterprise contexts. This then requires agencies to transition to use of the ESRI platform exclusively for geospatial work. Projecting into the future, if there were 2 competing OGC service types and ESRI were to drop support for the older W*S family of OGC services (or merely push support for them out of the core packages and into an expensive interoperability add-on), this would place many agencies in a situation of only being able to serve the newer standards, effectively killing the older standards within those contexts... Of course, isn't it funny, that it's getting harder and harder to find ESRI stuff anywhere, government or not. Lot's of enterprise Google Earth, and Google Maps Engine though. Of note: I recently moved from the DoD world to the transit world. I expected to find a lot of fleet management software built on top of ESRI tracking server. Nope, everything uses Google Maps. Even the aircraft tracking stuff that used to run on ESRI seems all to be Google based these days. Miles Fidelman -- In theory, there is no difference between theory and practice. In practice, there is. Yogi Berra ___ Discuss mailing list Discuss@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/discuss
