[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." ]
-mpg
________________________________
From:
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.
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
The OGC: Helping the World to Communicate
Geographically
---------------------
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
Keller
-------------- 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