Ciao Andrea,
it seems to me that you are victim of the confusion and of the
misconceptions that someone inside the geotools community has
generated in the last months, especially about the imageio-ext
project.
I will try to explain what we are doing once again quoting an old
email of mine. I am sure someone will speak for the coverageio work.
>>
We are splitting our work in levels, from imageio to geoserver
<IMAGEIO>
- Daniele, Alessio and partly me have been working at the lowest
imageio level trying to implement imageio readers with no geospatial
notion for
-- netcdf-cf (pure java)
-- grib1 (soon grib2 as well) pure java
-- various hdf profiles, using the NCSA java bindings, which we
have rewritten from scratch since we were having all sort of failures
Note that for the moment we refer to these plugins as the "flat" plugins.
This work has been recently (after a long discussion with a client
:-)) moved to the spike directory of the imageio-ext project here:
https://imageio-ext.dev.java.net/source/browse/imageio-ext/spike/nd-work/
The project is open source and there is a decent extent of
documentation. We have plans to work on these plugins until the end of
next summer adding other formats as well like more HDF profiles,
HDF-EOS and, depending on some NDAs I have signed JPEG2000.
Note that all this is independent from the gdal-based plugins.
- We have tried to cooperate with the GeoMatys guys on the definition
of a set of spatiotemporal metadata in order to write geospatial
enabled Imageio plugins.
This work is captured in this google document
ttp://docs.google.com/Doc?id=dgcvg3gc_34cpxtgkkv&hl=it but the actual
implementation is actually in out svn, since it is an ongoing effort,
but we could make it available.
<GeoTools>
This is where we are mostly working right now:
- Jody Garnett together Daniele (and some limited feedback from
myself) is working on implementing a replacement for the old coverarge
I/O API, namely the GridCoverageEchange API, which have been
deprecated since ages. We might want to put together a proposal to the
GeoApi project afterwards in order to replace the old GCE.
This work is going on under the geotools spike directory in the svn
(geotools trunk branch)
-Daniele and Alessio are working on implementing what we call "smart"
Imageio readers for netcdf-cf, hdf-avhrr and grib1. A smart reader is
simply a wrapper for a flat reader which add geospatial metadata to
it. We are still talking about 2D raster data but with geospatial
metadata describing detp/elevation, CRS, bbox, time, etc... This in
the future should reside inside GeoTools since it would depend on
other Geotools core modules
This work is actually on our private svn, but we could make it available.
- Jody Garnett and Daniele are working on building new geotools
plugins which would leverage on the above mentioned smart readers in
order to build coverages out of 2D rasters. For the first deliverable
we should just produce 2D coverage but in the future we are looking
into going a step further (iso 19123 or something similar I guess)
This work is actually on our private svn, but we could make it available.
<GeoServer>
- Alessio has already implemented and committed the EMF bindings to
allow GeoServer 1.7.x to parse
BAND,TIME,DEPTH/ELEVATION params in the GeoServer. The work in under
revision and should be committed soon.
Note that for the TIME parsing we reused the temporal work done byt GeoMatys.
- Alessio is working his way through refactoring the UI and
configuration of GeoServer using stubs of the new CoverageIo
interfaces which jody is defining in order to make possible to serve
2D coverages out of multidimensional ones for netcdf-cf, grib1 and
hdf-avhrr.
We are targeting mid sept to have a working demo for WMS 1.1.1 and WCS
1.0. Afterwards we will work on WMS 1.3 and WCS 1.1. The end goal is
to have the GeoServer able to do animations from WMS and return
multidim coverages (netcdf-cf as an instance) from WCS, but for this
are talking about next year much probably.
>>
Now a litlle clarification.
Imageio-ext was born to enhance the capabilities of imageio and it is
dedicated to high-perf raster I/O, I actually (let's put it this way
to be diplomatic) don't know
how come your statement that imageio is for visualization even because
it bases a large part of it code on GDAL and its work is basically
reading/writing raster data.
So the way I see it is simple, what you doing, building an imageio reader
for binary GRASS grids is the first step of a longer journey whose end
can be whatever you want, visualization, processing, wrapping in
another library, etc...
Of course the point for you should be whether or not the capability
offered by imageio (and as a consequence imageio-ext) are what you
need or not.
As I said, someone else for sure will talk about other possible
approaches, hopefully without throwing wrong statements on other's
people work in the mix, like it has happened in the last months.
Ciao,
"enthusiastic GeoSolutions code" Simone.
On Wed, Aug 27, 2008 at 6:33 AM, andrea antonello
<[EMAIL PROTECTED]> wrote:
> Hi list,
> this will sound strange, but since I tend to stay in the udig life and
> not to get my hands too dirty in geotools, this comes all new to me.
>
> I followed some fighting of the coverage gods in the past. But what I
> noticed only recently is that there are two separate efforts on the
> coverage side (is this the moment many of you are saying that this is
> no news? well I didn't know and probably others do not).
> I don't want to enter the philosophical part of this story, but since
> now I need to finish my port to geotools of the GRASS raster
> reader/writer, I need to discuss a bit.
>
> My impressions is that the two trails are somewhat different:
> - imageio-ext seems to be dedicated to imagery and its optimization in
> visualization
> - coveragio seems to be more scientific and with the need to follow
> strick the standards
>
> I agree that this is a very superficial analysis, which is more due to
> my current needs than to other things
>
> In fact JGrass is a scientific library for terrain analysis and we are
> going to propose at the next openmi tecnical meeting some spatial
> implementations, for which it is mandatory for us to follow strict
> standards.
> Basing on these facts coverageio seems to be the proper choice for us,
> even if we already started on the imageio-ext side.
> I'm getting a headache...
>
> Please, can I ask for some comment on all this,
> Thanks,
> The piano player
>
>
>
> PS: don't shoot the piano player
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Geotools-devel mailing list
> Geotools-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
-------------------------------------------------------
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 the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
