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

Sun Sep 9 09:09:00 EDT 2007

Hi all,

the document and XML schema can be found here
https://www.geo-solutions.it/svn/repo/documentation/imageiometadata_for_nd_coverages/

For public access (read only) you can use the following credentials:
username:pub
password:geosolutions

For Marin, I will send you the credentials with write permissions in a
private email.

Regards,
         Alessio.

On 9/7/07, Simone Giannecchini <simboss1 at gmail.com> wrote:
>
> 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 :-).
>
> <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.
>
> 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
>
> -------------------------------------------------------
>
> -------------------------------------------------------------------------
> 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
>

-- 
-------------------------------------------------------
Eng. Alessio Fabiani
Vice-President /CTO GeoSolutions S.A.S.
Via Carignoni 51
55041  Camaiore (LU)
Italy

phone: +39 0584983027
fax:      +39 0584983027
mob:    +39 349 8227000

http://www.geo-solutions.it

-------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/standards/attachments/20070909/8924e8c4/attachment-0001.html