<div dir="ltr">Hi Adrian,<div><br></div><div>Thank you very much for taking the time to provide this really useful summary of everything that is going on at OGC.</div><div><br></div><div>We're particularly grateful for your recent efforts helping to structure the Ideas4OGC process following the concerns that were raised by the GeoServices specification.  We all rely on OGC standards and everyone here feels much more comfortable knowing that people like you work behind the scenes on behalf of our broad community.</div>

<div><br></div><div>I'm copying in Denise from OGC to start an open discussion on whether we could jointly host an OGC-OSGeo Bird of a Feather session at FOSS4G in 4 weeks time. If Denise agrees then I'll add a slot to the wiki:<br>

</div><div>  <a href="http://wiki.osgeo.org/wiki/FOSS4G_2013_BirdsOfAFeather">http://wiki.osgeo.org/wiki/FOSS4G_2013_BirdsOfAFeather</a></div>
<div><br></div><div>I encourage other people on the list with an investment in standards to consider taking the membership that is now available.  I'm happy to discuss this with anyone who is interested.</div><div><br>

</div><div>Ian</div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Aug 15, 2013 at 4:14 PM, Adrian Custer <span dir="ltr"><<a href="mailto:acuster@gmail.com" target="_blank">acuster@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello all,<br>
<br>
you have nicely allowed me to use one of the OSGeo membership slots for OGC. As part of that, I am required to submit a report to you on OGC activity, or, really, on my activity at the OGC. Since my activity at the OGC is coming to an end, I submit this closing report to all of you.<br>


<br>
<br>
<br>
<br>
<br>
<br>
The OGC is continuing in much the same way with a major new interoperability testbed starting up, new standards up for a vote, proposed standards coming up for discussion and comment, and a TC meeting planned for late September just outside Rome. Additionally, there is some activity attempting to identify and propose solutions for some of the issues with the OGC today.<br>


<br>
<br>
The 10th iteration of the OGC interoperability testbed has been announced:<br>
  <a href="http://www.opengeospatial.org/projects/initiatives/ows-10" target="_blank">http://www.opengeospatial.org/<u></u>projects/initiatives/ows-10</a>.<br>
The RFQ/CFP is available at<br>
  <a href="http://www.opengeospatial.org/standards/requests/103" target="_blank">http://www.opengeospatial.org/<u></u>standards/requests/103</a>.<br>
A quickstart guide is<br>
  <a href="http://www.opengeospatial.org/pub/www/ows10/rfq/quickstart.html" target="_blank">http://www.opengeospatial.org/<u></u>pub/www/ows10/rfq/quickstart.<u></u>html</a><br>
Responses are due by 5 pm EST on 26 August 2013.<br>
<br>
<br>
<br>
<br>
Several standards are undergoing adoption votes including OpenMI version 2.0 and the CRS extension to WCS. There has been no general discussion about either of these on the TC Discussion list so I presume they will be adopted when the vote closes.<br>


<br>
<br>
<br>
<br>
WCS continues its incredible progress driven by the inexhaustible productivity of Peter Baumann. I am less aware of the work of other groups like catalog, processing services, feature services and observation services. There is ongoing work on SPARQL and on the semantic web.<br>


<br>
<br>
<br>
<br>
The PubSub standards working group feel they are close to releasing their draft specification for comment, first inside the OGC and then to the public. The group is motivated by work on the next generation US Air Traffic Control system and the need for actors to get regular updates, say on weather in a flight corridor, over a specific period of time. The specification provides a different messaging pattern from the standard request-response pattern used by most OGC web services. The idea is that some client could subscribe some recipient to a publication stream for a period of time. They decided that subscriptions should be temporary and expire. They also decided (but may be reconsidering) that the service should be setup as a new, separate 'PubSub Service' rather than being an extension to existing services. They have developed ways for the service to provide its capabilities including defining its publication offerings and any supported filtering system for the published messages. I have worked with that group fairly intensely these past few months, trying to help them with their writeup (introductory material) and their injunctions. I think they have understood my ideas and now will have to integrate what of those they find useful. Hopefully, that document will be released for comment soon and for public comment thereafter because it may interest some of you.<br>


<br>
<br>
The MetOcean folk must be very close to final publication of their recommendations on the use of "time" and "elevation" in OGC web services. Folk from several national meteorological agencies arrived a few years ago wanting to serve the output of their general circulation models as WMS layers. However, the results of any particular parameter, say air temperature or wind speed, are available in many different 'dimensions': according to the moment being predicted, according to the moment the model run stopped accepting input data, according to the last moment when this data should be used for some purpose, and at various heights in the air column measured in multiple different ways. Since they all use slightly different language to discuss these 'dimensions' they needed to get on the same page semantically and linguistically and, in particular, agree how to expose their data in a way that would work for each of them, a way that they all could share, and a way that would work for regular folk without special knowledge (i.e. with sane defaults). They have started that standardization work by defining rules for the use of the dimensions called 'TIME' and 'ELEVATION' in WMS. I have worked with them intensely this past year helping them better organize their paper, and better express their requirements. As a result we stumbled on a way to organize their work systematically which helps give them confidence that they have tackled most major issues. They sound happy with the results of their recent work. That document should be officially published this year. You can follow the work of the group on their public wiki:<br>


  <a href="http://external.opengis.org/twiki_public/MetOceanDWG" target="_blank">http://external.opengis.org/<u></u>twiki_public/MetOceanDWG</a><br>
<br>
<br>
<br>
<br>
<br>
<br>
The Web Map Service (WMS) standards working group has lost its steam and its forwards momentum. There are a few outstanding issues on WMTS (Web Map Tile service) that might be resolved in the next while. However, the working group is down to three people attending regular meetings and no progress being made. We recently tried to revive regular meetings again and heard feedback from some NASA folk providing lots of earth surface imagery. Then we worked through my proposal for an abstract fundamental map model to underlie our work on WMS 2.0 and its future extensions. However, we have not met again since then and with the fall work load arriving I am not hopeful that much work will get done going forwards. I expect the group will eventually dissolve. Fortunately, all the work we have done is up on a wiki so it should be easy for some future effort to review our work and decisions.<br>


<br>
My work on WMS 2.0 has failed. I have spent the past two or three years working intensely on a fully defined, fully testable, fully modular WMS. This work was motivated by the outstanding change requests pointing out issues with WMS 1.3.0 in its handling of languages, in its handling of dimensions, in its handling of axis-order issues, in its lack of a fully defined XML message form, and in its inability to scale for the needs of the meteorology community. The work was also motivated by new rules at the OGC that our standards should be written more clearly, with all injunctions visibly isolated, written against a specific 'target', accompanied by tests (so that only injunctions which can actually be tested are made), and grouped into coherent modules of injunctions. I was motivated by a vision of how to write better standards, how to fully solve issues all the way down to their theoretical foundations, and how to build OGC Services in general which are well written, comprehensible, and unambiguous. I also felt that if we required the use of something, say PNG, we ought to at least read that specification, so I have read intensely fourty odd standards of the IETF, the W3C, ISO and other organizations. The work turned out to be huge: starting with a large ambition, it soon spread out to become overwhelming. Also, I started with an active group and presumed I would get help from others at the OGC along the way but, unfortunately, SWG member activity dwindled to nothing and other groups at the OGC did not provide the support I needed.<br>


<br>
Despite that, I made a lot of progress. I rewrote the OGC standard on how to write standards into a coherent whole whose injunctions and tests helped me write better drafts. (That is pending review indefinitely because, despite being part of the OGC rules for new standards, there is no one to read it and accept it as a new version.) I developed a new model of spatial referencing based on an explicit description of all the semantic elements required to spatially cross-reference positions on two different objects. I then used that semantic model to analyze the current OGC abstract model and the OGC data model and data structures for referencing information (ISO 19111). That analysis showed that the current model fails to correctly define or express a 'datum' and is confused about how to define a coordinate system. This does not matter in practice because most of the time these are not needed in GIS systems, which need intra-crs transforms instead. However, it does matter for imagery and I showed how we should fix it and fixed it for PNG. (I even made an initial pass at a GeoPNG specification.) I developed an abstract model of OGC Services which considers a service as offering an endpoint over some transport system which accepts messages which have an encoding, a form, and a semantic model. This service model means that the injunctions made of the service can all be about how it recognizes and handles those messages. Finally, I developed an abstract model of maps which would eventually allow us to deal with movies and slices through the atmosphere and map decorations and piece-wise projections but which, at first, would quickly simplify down to the layer stack model of current WMS. These abstract models all fed my work defining injunctions for the use of encodings, message forms, and service behaviour. For the encodings,  I defined a restricted form of UTF-8 that adopted UTF-8 suggestions as requirements and I defined several profiles of common image formats (PNG, TIFF, GeoTIFF, ...) which serve primarily to remove ambiguity about the initial 'orientation' of the image from which spatial referencing will happen. For the message forms, I defined a use of text restricted to non-problematic UCS code points, defined a Key-Value form based on a formal ABNF grammar and its expression as either part of the URL <query> element or as a text file, and also defined three different 'forms' of XML: 'usable xml', 'bindable xml' and 'canonical xml' which might be used in different realms by WMS or its extensions. For the message semantics, I developed a Map Request model based on the map model I discussed earlier and worked to formalize some of the semantics of core OGC messages like the common XML based exception report. Finally, I tackled the behaviour of services starting with a lot of work trying to find a minimal set of proper behaviour in the handling of HTTP for OGC web services to address the network scalability issues at the heart of HTTP/1.1 without putting too much work on the shoulders of implementations. We have now just gotten to the 'fun' stuff, that is the proper behaviour of a Map Service itself in the handling of map requests. One of the great difficulties of all this work was figuring out how all the formal injunctions could properly fit one on top of the other, starting with abstract rules for generic services and working through more and more concrete versions of the services. Anyhow, this was a fair bit of work and I got really far. However, without support, feedback, or even encouragement, and with every step along the way just broken enough that it needed fixing, it was too much for me to bring this work to completion. It will be for the next person to try to make progress on WMS, either within the OGC or outside it.<br>


<br>
<br>
<br>
<br>
Finally, the OGC has embarked on a effort to take stock and address issues in its structure, its activities, and its understanding of itself. This self-reflection grew out of the recent fiasco that exploded all the way to this OSGeo list regarding the attempt to take the ESRI GeoServices specification and develop it into an OGC Standard. Someone at the OGC, the Board of Directors and/or Staff, decided to launch a formal review and called it the 'Ideas 4 OGC' effort. I joined that effort and pitched in a lot of the early content you will find on the public wiki<br>


    <a href="http://external.opengeospatial.org/twiki_public/Ideas4OGC" target="_blank">http://external.<u></u>opengeospatial.org/twiki_<u></u>public/Ideas4OGC</a><br>
and started some discussions, initially on the new TC-Discuss list, and then on the list of this particular effort. The group is just now starting to get organized and start actual work on the issues. The goal is to produce a report by the end of September presenting these issues to 'the OGC' and suggesting possible avenues for the resolution of the issues. Unfortunately, you cannot follow the work because the group has decided to switch to an internal wiki partly due to some folk not being allowed by their government employers to talk to the public. (Are you in deep trouble when you sacrifice transparency in order to have a frank discussion about the lack of transparency?) I pitched in a bunch of issues and suggestions for their resolution so the OGC has material that it could tackle if it decides it wants to. However, I am not interested in getting the OGC to 'want to' or pushing to get some of these fairly serious issues tackled. The biggest issue seems to me a lack of communication so that no one knows what the different responsible committees have been doing. A second major issue is that there is no oversight so that no one can or does refocus the work of anyone else for the benefit of the whole. My overall conclusion is that the Board of Directors needs to step up and do its directing work. Personally, I doubt I will be able to foster the changes needed to get the OGC working effectively writing clear standards, building well architectured systems, or running effective services. I think I have done what I could in the process and now it is for others to see it through. Overall, I am not hopeful that the OGC is institutionally capable of fixing itself and keeping itself fixed. However, the OGC will keep doing useful, if less than stellar, work for a long time in its current state.<br>


<br>
<br>
<br>
<br>
So that is a personal take on the OGC and my activities there these past few months.<br>
<br>
I have now resigned my membership in the OGC so there is another slot open if any of you can be and want to be individual members of the OGC.<br>
Thanks again for letting me use one of the OSGeo membership slots at the OGC,<br>
<br>
cheers,<br>
  ~adrian<br>
<br>
<br>
<br>
______________________________<u></u>_________________<br>
Discuss mailing list<br>
<a href="mailto:Discuss@lists.osgeo.org" target="_blank">Discuss@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/discuss" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/discuss</a><br>
</blockquote></div><br></div>