[OSGeo-Discuss] Summary of OGC Activity

[Adrian Custer]

Hello all,

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.






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.


The 10th iteration of the OGC interoperability testbed has been announced:
   http://www.opengeospatial.org/projects/initiatives/ows-10.
The RFQ/CFP is available at
   http://www.opengeospatial.org/standards/requests/103.
A quickstart guide is
   http://www.opengeospatial.org/pub/www/ows10/rfq/quickstart.html
Responses are due by 5 pm EST on 26 August 2013.




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.




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.




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.


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:
   http://external.opengis.org/twiki_public/MetOceanDWG






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.

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.

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.




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
     http://external.opengeospatial.org/twiki_public/Ideas4OGC
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.




So that is a personal take on the OGC and my activities there these past 
few months.

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.
Thanks again for letting me use one of the OSGeo membership slots at the 
OGC,

cheers,
   ~adrian