Geoservices REST API, an implementation specification by Esri which was to come up for voting for adoption at OGC, has created uproar in the geospatial community. Even though Esri has now withdrawn the specification from voting, questions remain over OGC’s role and vision
On May 8, an email landed on my computer with the subject line ‘Is the OGC losing its way?’ Attached to this email was a letter from the OGC Interoperability Movement Team Leaders, a group comprising concerned OGC members but not endorsed by OGC, sent to all the OGC Technical Committee members that stated in the preamble that “an important OGC event deserves your immediate attention. This note is in reference to a vote that is taking place at OGC on a proposed specification named ‘OGC GeoServices REST API’. If approved, it will have costly, far reaching, negative impacts on interoperability, and significantly tarnish the OGC’s reputation as a champion of interoperability”. Subsequently the Open Source Geospatial Foundation, OSGeo which has a MoU with OGC, issued an open letter signed by 134 professionals which went on to state, “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”. (This letter can be viewed at https://download.osgeo.org/osgeo/ ogc/open-letter-to-ogc.pdf.)
Geoservices REST API is an implementation specification developed by Esri and submitted to OGC by Esri Inc, Interactive Instruments GmbH, Oracle USA and 52°North. The draft standard document states in the preface that:
- The “Esri GeoServices REST Specification Version 1.0” was originally developed by Esri to provide interoperability between ArcGIS Server and the broader information technology community. The Esri specification had been widely implemented by Esri users and business partners over four years. In 2010, it was released as a non-proprietary open specification and has been implemented by developers outside of the Esri user community.
- In 2011, Esri has offered the GeoServices REST API for consideration to become an OGC standard. An OGC Standards Working Group has been formed to document the specification in conformance with the modular specification policy of the OGC and to address comments received from the OGC membership and during the public review.
This candidate standard is designed to be implemented without the use of Esri products. (The full draft standard can be downloaded from www.opengeospatial.org/ standards/requests/89) REST stands for Representational State Transfer, a software architecture that enables quick and easy access to Web services. It also provides a uniform interface which separates clients from servers. Thus clients do not need to know the inner details of servers and servers do not need to worry about client-user interfaces. Servers can scale up as needed and both servers and clients can be developed independently without affecting the services provided the REST interface is not disturbed. This is also known as loose coupling or coarse-grained architecture. Without going into further details, it is easy to see that in the geospatial world, REST is the way to go for Web services like CSW, WMS, WFS, WCS, etc.
What is the issue?
The issue is that OGC already has standards for these services, so what is their relation to the proposed Geoservices REST API? Unfortunately the draft specification merely maps the proposed specifications to the existing specifications and does not address the issue of interlinking the two such that they are interoperable.
Two statements in the document 12- 062r1 ‘GeoServices REST API — relationship with the OGC baseline’ are worrying.
- The first is: “While it would be possible to develop new versions of the OGC Web Services standards using a consistent framework and with support for JSON representations and a RESTful ‘binding’, this will likely take significant time due to the unresolved REST-related discussion items, the current organisation of OGC SWGs based on the individual standards and the fragmentation into separate standards.’ Standards should not be adopted on the basis of shortage of time, particularly when there are unresolved issues.
- The second is: “A key difference between the GeoServices REST API and the OGC and ISO 19100 standards is that the underlying data model is firmly based on the data model of an underlying database that supports SQL and Simple Feature for SQL (SF-SQL). The OGC standards on the other hand in general use models that are based on the capabilities of UML or XML Schema.”
Why has it to be an ‘underlying database’ that supports SQL; why not an SQL database itself which follows SF-SQL? The XML schema used to define GML schema is in no way a data model but a model for data representation and transport. The OGC supported data model is the Simple Feature model for SQL.
It also states that the current version will be backward compatible to all existing Geoservices REST API implementations. Since such implementations are primarily based on the Esri ArcGIS server technology this is seen to give Esri and its partners an unfair advantage in the marketplace. Further it adopts JSON (JavaScript Object Notation) as the data interface format and all future versions which may be proposed by other vendors has to have request parameters and JSON representations which are compatible to previous versions. However, OGC clarifies that backward compatibility is not essential. It depends on what the members consensus.
In any case, where does this leave the OGC Simple Features Specification and GML? There are other technical limitations like the HTTP methods PUT and DELETE are not used and POST is limited to those supported by HTML “due to limited support for HTTP in existing web client frameworks”. What limitations and why assume that these limitations will not be overcome in the future?
The undercurrents
According to an informed source, Esri has put up this proposal ‘in good faith’ but others have jumped the gun. The market realities also have a large role to play in this. Most governments like the US, UK and India stress open systems to encourage competition among vendors so that the customers get a good deal. It is a view amongst many that Esri, by offering its existing implementation as an open specification, can steal a march on the competition and always remain ahead by offering its enhancements as improvements on the adopted standard.
Vendors who currently offer OGC-compliant Web services will then have to face a double challenge. They will have to create new services as per the draft specifications and get them certified by OGC. They will also have to explain to the customers the difference between their offerings of Geoservices REST API and vanilla W*S.
Most customers do not understand OGC compliance certification and think it is like ISO or SEI CMMI. OGC tests commercial products for compliance of only OGC Web services (W*S) standards and GML Schema and is particularly pernickety about how products are labelled. Just ‘OGC certified’ is not enough; the certification label must specify the specific service and service version and the term ‘compliant’ can only be used if the specific vendor software version has undergone the OGC compliance testing successfully; otherwise the correct terminology is ‘implementing’. To add to this confusion, since OGC does not test for Simple Feature compliance, this feature can only be ‘implementing’ and not ‘compliant’. However, OGC now also offers GML Schema compliance testing and a slew of other tests for compliance will follow. Explaining all this to customers is tiresome and will become more so with the new specification for REST API if it is adopted as is.
Perhaps realising all these issues, Esri has withdrawn the specification from voting for adoption. It continues with the SWG for further discussions and hopefully, amendments to overcome these issues. To be fair to Esri it should be noted that their offering of their shapefile as an open implementation has greatly helped the geospatial community. Similarly, the KML encoding standard developed by Google has been accepted by OGC as one of their standards. Even in the present case, the Geoservices REST API addresses a need for an integrated suite of services using simple data encodings. Though partial in its implementation, it does push OGC to move in this direction. In fact, many developers have been working on REST for W*S implementations and there is a version of JSON termed GeoJSON which shows that this is the way the industry would like to move. GeoJSON’s data model is based on ISO 19107 and is also consistent with GML and KML. Though OGC asserts that there is a plan to provide a GeoJSON encoding pattern for the next version of the candidate standard, all this exposes the weakness of OGC in spearheading such moves.
OGC specifications are widely referred in the GSDI SDI Cook Book but some accuse OGC of not pushing for standards for an Open SDI and waiting passively for any three members to form a SWG on whatever issue that takes their fancy. But according to OGC, the matter does not end there. The GeoREST Services and all other SWG charters are subject to review and approval by the OGC Technical Committee. Further, all draft SWG Charters are publicly announced and available for public review and comment. This does not explain why OGC does not push for an open SDI focussing on identifi ed issues and their solutions. However, OGC points out that a number of key OGC initiatives are the result of staff facilitating the process and encouraging members to bring candidate standards into the OGC or to start new standards initiatives that are well aligned with current market and business trends. Examples are numerous, such as the new Point Of Interest work, Internet of Things standards activities, liaison work with the Augmented Reality community and so forth.
So what is in store for the geospatial users?
Some feel that adoption of the Geoservices REST API as a standard would benefit the geospatial community. They feel that waiting for a ‘good’ RESTful API standard to evolve would take at least two years by which time the technology would have moved on. The same fact is used by those who oppose the adoption to point out that the proposed draft standard is based on existing technology. There is a published document whitepapers/pdfs/geoservices-rest-spec. pdf) already available and therefore there is no need to have this adopted by OGC merely for interoperability with Esri implementation.
To meet the challenges of the future, it does not make sense to adopt what is already a well-established engineering document. OGC standards need to look beyond the immediate and address the foundations of SDIs between nations. This role is measured in decades and not years therefore OGC need to start with a new design that can be supported over the next two decades. However, OGC feels that this criticism is unfair as it has a vision for the future of SDI which is well articulated in its recent blogs and presentations.
In closing, standard conflicts are not new, and results can be startling. In the 1980s, there was a huge conflict between Sony’s Betamax and JVC’s VHS in the field of home video tape recorders. VHS emerged the winner because it offered a lower cost and longer recording times. In the case of digital video recording also there were two standards — MMCD and SD — supported by different groups of manufacturers. In the 1990s, both groups approached IBM for help on file formats. Keeping the Betamax-VHS conflict in mind IBM convened a technical working group which rejected both formats and through a process of compromise came out with the DVD specification which holds to this day. Is there a lesson in this?
Another organisation which is deep into standards development is the IEEE. A study of the process of developing IEEE standards is worth considering. Among other aspects, the standards undergo extensive testing and the balloting process requires 75% return with 75% approval by the balloting group which consists of persons who are members of the IEEE-SA and are interested in the standard. This is definitely an improvement of the OGC balloting method of 50% plus one. Given the contentious issues besetting the Geoservices REST API specifi cation, OGC may like to look into some of these aspects as well. It should be pointed out that many OGC standards do undergo testing prior to release as a standard. Using candidate standards in Interoperability Experiments, OGC testbeds, and so forth insures some level of maturity of the standard before it is approved. However OGC concedes that they can improve in this area and are always looking for ways to improve the quality of their standards.
OGC has not lost its way but is at a crossroad and members need to help it along to find the best route to a bright future. The key has to be collaboration and compromise and enlightened leadership.
Disclaimer: The views expressed in this article are that of author and Geospatial World does not necessarily subscribe to the sentiments expressed.
