Hi all,<br><br>the document and XML schema can be found here<br><a href="https://www.geo-solutions.it/svn/repo/documentation/imageiometadata_for_nd_coverages/">https://www.geo-solutions.it/svn/repo/documentation/imageiometadata_for_nd_coverages/
</a><br><br>For public access (read only) you can use the following credentials:<br>username:pub<br>password:geosolutions<br><br>For Marin, I will send you the credentials with write permissions in a private email.<br><br>
Regards,<br> Alessio.<br><br><div><span class="gmail_quote">On 9/7/07, <b class="gmail_sendername">Simone Giannecchini</b> <<a href="mailto:simboss1@gmail.com">simboss1@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Ciao Jody,<br>my bad the document did not float around from the start, I think there<br>was a misunderstanding between me, Martin and Daniele. But let's put<br>things in context :-).<br><br><A bit of history first for whoever may be interested. >
<br><br>Since I started working with OGC standards more or less 3.5 years ago<br>I noticed that while there was an adopted Grid Coverage Implementation<br>Specification many other documents where implicitly referring to ISO
<br>19123.<br>I also felt not comfortable with the fact that there were/are so many<br>different discussion papers/abstract specifications/implementation<br>specification and so on trying to come up with a way to<br>encode/model/represent GridCoverage metadata, like georeferencing,
<br>quality metadata, usage metadata, sensor model metadata, etc....<br>The bad news is that, IMHO, the situation is not improved over the<br>time, well to be honest I think things are getting more intricate,<br>since new documents are coming up during the time.
<br><br>To summarise, the problems I see:<br><br>1>A lot of documents, as I said, refer to ISO 19123 implicitly while,<br>afaik at least, GridCoverage IS is still THE adopted specification for<br>GridCoverage, afaik at least.
<br><br>2>ISO 19123 is not available for free, hence this can be a show<br>stopper for people(I know it is not expensive but still, many OGC<br>documents are referring to an ISO specification that you are supposed<br>to pay for. (Well, IMHO, this is quite strange, what does Open stand
<br>for in the acronym OGC? :-) ).<br><br>3>GridCoverage IS was made of mainly 3 parts (as far as I can remember<br>at least :-) )<br> - GridCoverageExchange that proposes a model for I/O<br> - GridCoverageProcessor that proposes a model for GridCoverage Processing
<br> - GridCoverage that proposes a model for GridCoverage<br><br>Well ISO19123 does NOT propose anything about I/O or processing<br>itself. There might be other ISO specs, I admit my ignorance about<br>this, but I also admit that I do not want to get into the Dependency
<br>Graph of ISO specs which could cost me a few thousands Euros :-).<br><br>So the problem here is that it apparently seems that the new de-facto<br>standard for GridCoverages is ISO19123 but the latter covers a<br>smaller area than GC IS. How are are we supposed to I/O and
<br>processing? (as I said other specs may be involved, no idea yet).<br><br><br>4>While GridCoverage IS make a shy attempt to deal with metadata, ISO<br>19123 leave the thing mostly aside. Is it good, is it bad? Not sure...
<br>Probably metadata should be handled somewhere else but I don't think<br>the situation can be improved just leaving asides.<br><br><br>5>While ISO 19123 seems to focus only on a model for Coverage it is<br>much more complex than the old GridCoverage IS hence it is not so
<br>attractive at first given also what I said above, at least IMHO :-).<br><br>There may be more, but I don't want to get you bored (maybe I alredy did it...)<br><br><Why this document><br>In the GeoTools/GeoServer community there has been a lot of discussion
<br>about how to "handle" multidimensional GridCoverages<br>(t,z,band,level,y,x). A lot of documents were produced (let me mention<br>the wonderful documents that Bryce Nordgren wrote) with many good<br>ideas but given lack of time/resources (and probably bad project
<br>managing?) not much was produced.<br><br>During the last months two different efforts are going on in order to<br>produce something useful. GeoSolutions has received a mandate to<br>investigate these problems and come up with a first solutions from
<br>NURC and other partners while Geomatys received a similar mandate from<br>IFREMER.<br>Since both companies make money out of GeoTools and GeoServer we<br>thought it would have been nice to cooperate. This is the good part.
<br>The bad part is that we have different deadlines and programs hence we<br>are trying to not step on each other's feet and concentrate on<br>different aspects of the same problems while still trying to<br>synchronize.
<br>This document is supposed to be (at least in my dreams :-) ) what<br>keeps us synchronized and in the end it should also try to make<br>proposals on how to correct the problem I pointed out above. We<br>probably may not succeed, but at least we tried! :-).
<br>It comes out of sparse note I have written in the past, but is has<br>undergone multiple reviews from Daniele, Alessio Fabiani and other<br>people. Since a couple of weeks we have started to share it with<br>Martin as well.
<br><br><br><Conclusion><br>There might be more to say but I am about to go running on the seaside<br>hence time for conclusions.<br>My idea was to start circulate the pdf in the geotools community and<br>then put the pdf of the document somewhere (suggestions?) in order to
<br>have people look at it ( right now it is under our svn). For the<br>moment I would restrict the write permission to me, Daniele, Alessio<br>and Martin because this is not simply a theoretical proposal, as I<br>said it captures ongoing work we are doing along with proposal for
<br>next steps, hence I think we should put some control on it. However I<br>am open to loose up this control a bit (suggestions? Ideas?).<br><br><br>Ciao a tutti,<br>Simone.<br><br>PS<br>Sorry, the email is too long.<br>
<br>On 9/7/07, Jody Garnett <<a href="mailto:jgarnett@refractions.net">jgarnett@refractions.net</a>> wrote:<br>> This is exactly what I am talking about ... why working with the OGC is<br>> messed up.<br>><br>
> Martin is in good faith trying to talk over some ideas with the<br>> community; but since we don't have the document he is working on it is a<br>> big old waste of time. What will happen? Martin will make some
<br>> interfaces using the document as a guide and then we will start the<br>> discussion again a month later.<br>><br>> Jody<br>><br>> Daniele Romagnoli from Geosolution recently send us a document on<br>
> Coverage I/O metadata. It sound like a very good draft to me. In the<br>> next bunch of emails, I'm going to comment some sections. I will send<br>> separated emails for different issues in order to create distinct
<br>> threads.<br>><br>> For this email, I will just raise minor issues on class namings.<br>><br>><br>><br>> AbstractSpatioTemporalCoverageReader (figure 3)<br>> -----------------------------------------------
<br>> If there is no SpatioTemporalCoverageReader, I would suggest to drop the<br>> "Abstract" prefix even if the class is abstract. This is a common<br>> practice in J2SE library: Reader, ImageReader, InputStream, Buffer,
<br>> DataBuffer, RectangularShape, Rectangle2D, Ellipse2D and much much more<br>> are all abstract classes. Really, the "Abstract" prefix or "Default"<br>> prefix are just for distinguish a default base implementation from the
<br>> interface it implements.<br>><br>><br>> ImageIOReader (figure 3)<br>> ------------------------<br>> "IO" is usually for "Input/Output". It is strange to have the "Output"
<br>> part in a Reader. I guess you are talking about the J2SE ImageReader?<br>><br>> Figure 4 also have a "AbstractImageReader". I'm not sure if you are<br>> talking about the J2SE ImageReader or a new class. I guess that this is
<br>> the J2SE one, in which case the "Abstract" prefix needs to be removed.<br>><br>><br>> Minor typos<br>> -----------<br>> Page 17: "For our purposes we will to try to respect ...". There is one
<br>> extra "to".<br>><br>> Page 21 in the table: "stirng" should be "string".<br>><br>><br>><br>> -------------------------------------------------------------------------
<br>> This SF.net email is sponsored by: Splunk Inc.<br>> Still grepping through log files to find problems? Stop.<br>> Now Search log events and configuration files using AJAX and a browser.<br>> Download your FREE copy of Splunk now >>
<a href="http://get.splunk.com/">http://get.splunk.com/</a><br>> _______________________________________________<br>> Geotools-devel mailing list<br>> <a href="mailto:Geotools-devel@lists.sourceforge.net">Geotools-devel@lists.sourceforge.net
</a><br>> <a href="https://lists.sourceforge.net/lists/listinfo/geotools-devel">https://lists.sourceforge.net/lists/listinfo/geotools-devel</a><br>><br>> _______________________________________________<br>> Standards mailing list
<br>> <a href="mailto:Standards@lists.osgeo.org">Standards@lists.osgeo.org</a><br>> <a href="http://lists.osgeo.org/mailman/listinfo/standards">http://lists.osgeo.org/mailman/listinfo/standards</a><br>><br>><br>
<br><br>--<br>-------------------------------------------------------<br>Eng. Simone Giannecchini<br>President /CEO GeoSolutions S.A.S.<br>Via Carignoni 51<br>55041 Camaiore (LU)<br>Italy<br><br>phone: +39 0584983027<br>
fax: +39 0584983027<br>mob: +39 333 8128928<br><br><br><a href="http://www.geo-solutions.it">http://www.geo-solutions.it</a><br><br>-------------------------------------------------------<br><br>-------------------------------------------------------------------------
<br>This SF.net email is sponsored by: Splunk Inc.<br>Still grepping through log files to find problems? Stop.<br>Now Search log events and configuration files using AJAX and a browser.<br>Download your FREE copy of Splunk now >>
<a href="http://get.splunk.com/">http://get.splunk.com/</a><br>_______________________________________________<br>Geotools-devel mailing list<br><a href="mailto:Geotools-devel@lists.sourceforge.net">Geotools-devel@lists.sourceforge.net
</a><br><a href="https://lists.sourceforge.net/lists/listinfo/geotools-devel">https://lists.sourceforge.net/lists/listinfo/geotools-devel</a><br></blockquote></div><br><br clear="all"><br>-- <br>-------------------------------------------------------
<br>Eng. Alessio Fabiani<br>Vice-President /CTO GeoSolutions S.A.S.<br>Via Carignoni 51<br>55041 Camaiore (LU)<br>Italy<br><br>phone: +39 0584983027<br>fax: +39 0584983027<br>mob: +39 349 8227000<br><br><br><a href="http://www.geo-solutions.it">
http://www.geo-solutions.it</a><br><br>-------------------------------------------------------