[OSGeo-Standards] [Fwd: [Geotools-devel] ImageIO MetaData]

Fri Sep 7 14:35:54 EDT 2007

Ciao Jody,
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 :-).

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.

On 9/7/07, Jody Garnett <jgarnett at refractions.net> wrote:
> This is exactly what I am talking about ... why working with the OGC is
> messed up.
>
> Martin is in good faith trying to talk over some ideas with the
> community; but since we don't have the document he is working on it is a
> big old waste of time. What will happen? Martin will make some
> interfaces using the document as a guide and then we will start the
> discussion again a month later.
>
> Jody
>
> Daniele Romagnoli from Geosolution recently send us a document on
> Coverage I/O metadata. It sound like a very good draft to me. In the
> next bunch of emails, I'm going to comment some sections. I will send
> separated emails for different issues in order to create distinct
> threads.
>
> For this email, I will just raise minor issues on class namings.
>
>
>
> AbstractSpatioTemporalCoverageReader (figure 3)
> -----------------------------------------------
> If there is no SpatioTemporalCoverageReader, I would suggest to drop the
> "Abstract" prefix even if the class is abstract. This is a common
> practice in J2SE library: Reader, ImageReader, InputStream, Buffer,
> DataBuffer, RectangularShape, Rectangle2D, Ellipse2D and much much more
> are all abstract classes. Really, the "Abstract" prefix or "Default"
> prefix are just for distinguish a default base implementation from the
> interface it implements.
>
>
> ImageIOReader (figure 3)
> ------------------------
> "IO" is usually for "Input/Output". It is strange to have the "Output"
> part in a Reader. I guess you are talking about the J2SE ImageReader?
>
> Figure 4 also have a "AbstractImageReader". I'm not sure if you are
> talking about the J2SE ImageReader or a new class. I guess that this is
> the J2SE one, in which case the "Abstract" prefix needs to be removed.
>
>
> Minor typos
> -----------
> Page 17: "For our purposes we will to try to respect ...". There is one
> extra "to".
>
> Page 21 in the table: "stirng" should be "string".
>
>
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >>  http://get.splunk.com/
> _______________________________________________
> Geotools-devel mailing list
> Geotools-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
> _______________________________________________
> Standards mailing list
> Standards at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/standards
>
>

-- 
-------------------------------------------------------
Eng. Simone Giannecchini
President /CEO GeoSolutions S.A.S.
Via Carignoni 51
55041  Camaiore (LU)
Italy

phone: +39 0584983027
fax:      +39 0584983027
mob:    +39 333 8128928

http://www.geo-solutions.it

-------------------------------------------------------