Simone, Adrian, Martin, Jody,
thanks for the indeep and somehow suffered efforth to give a further
explanation to the coverage trail.
As you can see by Michaels mail, I'm not the only piano man around
searching for the right song to play.
I understood a few important things:
- thank God I started all this by putting grass in imageio :)
- what I am interested in is in the gml4jpeg2000 and the
geo-solutions-matys metadata efforth
- I will study a lot and talk to people from the environmental
modeling sectors to query their needs also
- I will have a good time with all you cowboys in Cape Town (beer
makes friends, right?)
Then I will finally write that final part of code, hopefully following
the most standard way.
Your mails were very appreciated,
Thanks a ton,
Andrea
On Thu, Aug 28, 2008 at 4:24 PM, Jody Garnett <[EMAIL PROTECTED]> wrote:
> Martin Desruisseaux wrote:
>>
>> Jody Garnett a écrit :
>>>
>>> From the GeoTools library level both implementations are treated the same
>>> - as implementations of GridCoverageReader.
>>
>> Actually we don't have a common GridCoverageReader interface yet. GeoAPI
>> defined such an interface, but we did so only because it was part of OGC
>> 01-004 ("Grid Coverage implementation specification"). This is one of the
>> few metadata / referencing / coverage interface I never tried to implement.
>>
>> As far as "coverageio" is concerned, its present focus is toward J2SE
>> ImageIO API only - it is not yet commited to any GridCoverageReader API, so
>> the doors remind open in this area.
>
> Okay ... so we are happy with the now ISO based GridCoverage interface; and
> everything else is on the table. Got it.
>
> At a pragmatic level everyone is making use of the GridCoverageReaders
> directly using new; uDig was forced to go with the Abstract base class as
> the only common denominator with the existing implementations.
>>>
>>> The uDig community may of given you the impression that imageio-ext work
>>> was more focused on performance (because that is what we are excited about
>>> over there). At a low level they are all doing the same scientific work and
>>> take this stuff very seriously.
>>
>> imageio-ext supports a wider range of formats than coverageio, which is
>> still more focused on the fundation rather than supporting many formats.
>>
>> However coverageio focus on performance maybe through more complex
>> structures, with stuff like a RTree for managing the tiles in a mosaic,
>> image mosaic built directly at ImageReader.read(...) step rather than as
>> separated images assembled afterward with JAI "Mosaic" operation,
>> multi-threading, etc. The complexity of those structures make coverageio
>> slower to develop and to debug, but the execution speed is not bad.
>
> Sounds great, competition on the implementaitons and collaboration on the
> common api - exactly where an open source project wants to be.
>
> Cheers,
> Jody
>
-------------------------------------------------------------------------
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
