[Geotools-devel] Breakout IRC for GridCoverages?

[Jody G. <jga...@re...>]

Thanks for the great email martin, heck that should be on an RnD page=
=20
for later reference.  Since there is so much interest in GridCoverage=
=20
could we do a breakout IRC on the topic next week? I think you guys a=
re=20
on opposite sides of the world, but it is a breakout meeting perhaps =
we=20
can find a time suitable to both of you?

Jody
> I'm glad to see interest in GridCoverage :).
>=20
> About GridCoverage2D: Simone rightly point out that GridCoverage2D=
=20
> expects a RenderedImage at construction time. However, because of J=
AI=20
> deferred execution mechanism, a RenderedImage should take a negligi=
ble=20
> amount of memory until the pixel values are first requested. This w=
ill=20
> not work with java.awt.image.BufferedImage, but should work with mo=
st=20
> images produced by JAI. The fact that GridCoverage2D wraps Rendered=
Image=20
> in a PlanarImage implementation should not trigs pixel computation =
ahead=20
> of time.
>=20
> Because BufferedImage do not supports deferred execution, we should=
=20
> banish all methods from javax.imageio returning a BufferedImage. Fo=
r=20
> example we should banish ImageReader.read(...) and use=20
> ImageReader.readAsRenderedImage(...) instead. Or yet better, use=
=20
> JAI.create("ImageRead", ...) operation from JAI Image I/O extension=
 (yet=20
> an other download after the JAI's one), which should read pixel val=
ues=20
> only when a tile is first requested.
>=20
> I agree with Bryce that RenderableImage do not fits naturally with=
=20
> GridCoverage. GridCoverage (no matter which implementation) has kno=
w=20
> size with know resolution and know grid geometry. RenderableImage h=
as no=20
> know geometry; it can be an abstract mathematical formulae producin=
g=20
> values at any resolution. The natural matches in my understanding a=
re:
>=20
>     RenderedImage    -->  wrapped in two-dimensional GridCoverage
>     RenderableImage  -->  wrapped in two-dimensional Coverage
>=20
> A Coverage2D implementation for RenderableImage may be a valuable=
=20
> addition to Geotools.
>=20
> For big images (and I agree with Simone that JPEG2000 is probably t=
he=20
> way to go), I would rather try to make JAI's deferred execution wor=
k=20
> with tiled, pyramidal images. I believe it should work. If it doesn=
't,=20
> lets try to figure out where the pixels are computed ahead of time.=
 If=20
> the cause is on our side, lets try to fix that.
>=20
>=20
>=20
>=20
> simone giannecchini a =E9crit :
>=20
>> I think that the specifications on Coverages are somehow incomplet=
e
>> since they do not really take into account implemntation of 3d and=
 4D
>> coverages.
>=20
>=20
> Yes. Current GeoAPI is based on a legacy OGC implementation wich sh=
ould=20
> be replaced by ISO 19123. The great new is that I had a look on ISO=
=20
> 19123, and I believe that the transition can be done smootly.=20
> getCoordinateReferenceSystem and evaluate methods should stay there=
 for=20
> example.
>=20
> I put a first (partial) set of ISO 19123 interfaces there:
>=20
> http://cvs.sourceforge.net/viewcvs.py/geoapi/pending/org/opengis/co=
verage/
>=20
> The ISO 19123's Coverage interface may looks quite different from t=
he=20
> one we currently have, but actually it is not that much different. =
It=20
> contains much more additions than conflicts (for example I like a l=
ot=20
> their "evaluateInverse" method, even if it is going to be a lot of =
work=20
> to implement). It has only one "evaluate" method, but it is compati=
ble=20
> with our current "evaluate" methods (both in spirit and in the meth=
od=20
> signature) and doesn't prevent us to put all our current "evaluate"=
=20
> methods in addition, as more efficient ways to get the same informa=
tion.
>=20
>=20
>=20
> Now about the work that need to be done with GridCoverageExchange: =
this=20
> one is quite incomplete too. I hope to get more experience with geo=
tools=20
> implementation in order to suggest changes in GeoAPI interfaces. An=
yway,=20
> my proposal is:
>=20
> 1) Create a javax.imageio.metadata.IIOMetadataFormat implementation
>    matching the format described in "GML in JPEG2000" OGC specifica=
tion.
>=20
> 2) Implement all plugins as javax.imageio.ImageReader implementatio=
n,
>    and ask them to express their metadata (CRS, envelope, etc.) int=
o
>    an javax.imageio.metadata.IIOMetadata object. Which should be as
>    much independant as possible from GridCoverage at this stage.
>=20
> 3) Write a single GridCoverageExchange or Format implementation. Gi=
ven
>    an arbitrary javax.imageio.ImageReader, this generic implementat=
ion
>    should get the image data using JAI.create("ImageRead", ...)
>    operation and get the metadata in the format described above usi=
ng
>    the RenderedImage.getProperty("JAI.ImageMetadata") or
>    RenderedImage.getProperty("JAI.StreamMetadata") call. Those meta=
data
>    shall be used for creating the appropriate CoordinateReferenceSy=
stem
>    or Envelope objects. This way, we should be able to keep raster
>    plugins close to independant from GridCoverage (we basically nee=
d
>    to add to existing ImageReader the capability to express metadat=
a as
>    IIOMetadata object in the format described by "GML in JPEG2000")=
.
>=20
>     What do you think?
>=20
>         Martin.
>=20