NOTE: The galeon mailing list is no longer active. The list archives are made available for historical reasons.
I believe the note below relating to "coverages" is of interest to many of you. -- Ben
---------- Forwarded message ---------- From: Carl Reed OGC Account <creed@xxxxxxxxxxxxxxxxxx> Date: Sep 13, 2007 4:57 PM Subject: Re: [WCS.RWG] OSGeo email WRT OGC and coverage remail standards To: wcs.rwg@xxxxxxxxxxx, coverages.wg@xxxxxxxxxxxxxxxxxx I thought that the following might be of interest to the OGC members involved with coverages and imagery. Just underscores the need for a simple, well defined, well documented easy to implement interface with potentially an implementation primer associated with it. Hate to harp on this issue, but the open source world appears to have increasing implementation experience with coverages and their experience with OGC and ISO approaches has not been overly successful. Perhaps a dialogue with the appropriate folks in that community might be in order. Regards Carl my bad the document did not float around from the start, I think there was a misunderstanding between me, Martin and Daniele. But let's put things in context :-). <A bit of history first for whoever may be interested. > Since I started working with OGC standards more or less 3.5 years ago I noticed that while there was an adopted Grid Coverage Implementation Specification many other documents where implicitly referring to ISO 19123. I also felt not comfortable with the fact that there were/are so many different discussion papers/abstract specifications/implementation specification and so on trying to come up with a way to encode/model/represent GridCoverage metadata, like georeferencing, quality metadata, usage metadata, sensor model metadata, etc.... The bad news is that, IMHO, the situation is not improved over the time, well to be honest I think things are getting more intricate, since new documents are coming up during the time. To summarise, the problems I see: 1>A lot of documents, as I said, refer to ISO 19123 implicitly while, afaik at least, GridCoverage IS is still THE adopted specification for GridCoverage, afaik at least. 2>ISO 19123 is not available for free, hence this can be a show stopper for people(I know it is not expensive but still, many OGC documents are referring to an ISO specification that you are supposed to pay for. (Well, IMHO, this is quite strange, what does Open stand for in the acronym OGC? :-) ). 3>GridCoverage IS was made of mainly 3 parts (as far as I can remember at least :-) ) - GridCoverageExchange that proposes a model for I/O - GridCoverageProcessor that proposes a model for GridCoverage Processing - GridCoverage that proposes a model for GridCoverage Well ISO19123 does NOT propose anything about I/O or processing itself. There might be other ISO specs, I admit my ignorance about this, but I also admit that I do not want to get into the Dependency Graph of ISO specs which could cost me a few thousands Euros :-). So the problem here is that it apparently seems that the new de-facto standard for GridCoverages is ISO19123 but the latter covers a smaller area than GC IS. How are are we supposed to I/O and processing? (as I said other specs may be involved, no idea yet). 4>While GridCoverage IS make a shy attempt to deal with metadata, ISO 19123 leave the thing mostly aside. Is it good, is it bad? Not sure... Probably metadata should be handled somewhere else but I don't think the situation can be improved just leaving asides. 5>While ISO 19123 seems to focus only on a model for Coverage it is much more complex than the old GridCoverage IS hence it is not so attractive at first given also what I said above, at least IMHO :-). There may be more, but I don't want to get you bored (maybe I alredy did it...) <Why this document> In the GeoTools/GeoServer community there has been a lot of discussion about how to "handle" multidimensional GridCoverages (t,z,band,level,y,x). A lot of documents were produced (let me mention the wonderful documents that Bryce Nordgren wrote) with many good ideas but given lack of time/resources (and probably bad project managing?) not much was produced. During the last months two different efforts are going on in order to produce something useful. GeoSolutions has received a mandate to investigate these problems and come up with a first solutions from NURC and other partners while Geomatys received a similar mandate from IFREMER. Since both companies make money out of GeoTools and GeoServer we thought it would have been nice to cooperate. This is the good part. The bad part is that we have different deadlines and programs hence we are trying to not step on each other's feet and concentrate on different aspects of the same problems while still trying to synchronize. This document is supposed to be (at least in my dreams :-) ) what keeps us synchronized and in the end it should also try to make proposals on how to correct the problem I pointed out above. We probably may not succeed, but at least we tried! :-). It comes out of sparse note I have written in the past, but is has undergone multiple reviews from Daniele, Alessio Fabiani and other people. Since a couple of weeks we have started to share it with Martin as well. <Conclusion> There might be more to say but I am about to go running on the seaside hence time for conclusions. My idea was to start circulate the pdf in the geotools community and then put the pdf of the document somewhere (suggestions?) in order to have people look at it ( right now it is under our svn). For the moment I would restrict the write permission to me, Daniele, Alessio and Martin because this is not simply a theoretical proposal, as I said it captures ongoing work we are doing along with proposal for next steps, hence I think we should put some control on it. However I am open to loose up this control a bit (suggestions? Ideas?). Ciao a tutti, Simone. PS Sorry, the email is too long. ================================================================================== Carl Reed, PhD CTO and Executive Director Specification Program OGC
galeon archives: