[OSGeo-Standards] FW: [Coverages.wg] OSGeo email WRT OGC and coverage remail standards

Michael P. Gerlek mpg at lizardtech.com
Mon Sep 17 16:48:37 EDT 2007

[ Carl Reed gave me permission to forward the below note to this list.
He also notes that " the dialogue has begun thanks to some OGC members
who participate in the osgeo community" and that "the group needs to
know that 19123 will shortly be an OGC abstract spec document that will
be publicly and freely available. Should be available starting after
Sept 21st." ]




coverages.wg-bounces+mpg=lizardtech.com at opengeospatial.org
[mailto:coverages.wg-bounces+mpg=lizardtech.com at opengeospatial.org] On
Behalf Of Carl Reed OGC Account
			Sent: Thursday, September 13, 2007 3:58 PM
			To: wcs.rwg at opengis.org;
coverages.wg at opengeospatial.org
			Subject: Re: [Coverages.wg] OSGeo email WRT OGC
and coverage remail standards
			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.

			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

			I also felt not comfortable with the fact that
there were/are so  many
			different discussion papers/abstract
			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
			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
			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
			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
			(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
			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
			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.
			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,
			Sorry, the email is too long.
			Carl Reed, PhD
			CTO and Executive Director Specification Program
			The OGC: Helping the World to Communicate
			This communication, including attachments, is
for the exclusive use of addressee and may contain proprietary,
confidential or privileged information. If you are not the intended
recipient, any use, copying, disclosure, dissemination or distribution
is strictly prohibited. If you are not the intended recipient, please
notify the sender  immediately by return email and delete this
communication and destroy all copies.
			"The important thing is not to stop
questioning." -- Albert Einstein 
			"Security is mostly a superstition. It does not
exist in nature. Life is either a daring adventure or nothing." -- Helen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/standards/attachments/20070917/046a8323/attachment.html

More information about the Standards mailing list