Wednesday, 6 November 2013

Ideas4OGC - the phoenix rising from the "GeoServices REST API" ashes

You may remember the contentious proposal for the GeoServices REST API to become an OGC standard? After strong community concerns, largely focused on duplication of existing standards, the motion to approve the proposed standard was withdrawn. The fact that the proposal progressed as far as it did, to the point where it was almost ratified as a standard before being blocked, was a primary driver leading the OGC to initiate an "Ideas for OGC" (Ideas4OGC) review, aimed at re-baselining OGC priorities and processes.
Re-assessing OGC priorities and processes was timely. The OGC is almost 20 years old. OGC standards are now addressing broader and more complicated use cases than OGC's original focus, including mass market, mission critical and production uses. This leads to greater complexity, pressure to maintain consistency between standards, as well as higher requirements for robustness, quality, and clear documentation.
These drivers were fed into the Ideas4OGC initiative, and I've been impressed with the initial set of recommendations which clearly and concisely address OGC's revised priorities and objectives. Highlights include:
  • ... any [standard] coming to OGC .. should go through an “early” evaluation process to test the validity of adding it to the OGC baseline. ...
  • Early evaluation of [a] new domain's [uniqueness], usefulness and applicability  to OGC ...
  • ... strongly encourage internal harmonization of OGC standards  ...
  • Routine harmonization through regular standards maintenance. ...
  • Develop concise overviews for each standard for managers, architects and programmers. ...
  • Develop a set of accessible, concise summaries of OGC rules, policies and procedures ... 
  • Provide engineers/architects with [a] well-defined collection of guidelines, templates and tools  ...
  • Consistent editorial review ...
The next challenge for the OGC will be to re-prioritise sponsor focus on improving core quality over features. It is exactly what is required, but is a tough sell, as the value is much harder to quantify and justify than developing a standard for a specific use case.

No comments: