To clarify once again:

 - the grid coverage renderer code does NOT depend in anyway on the
arcgrid module, I just use the arcgrid reader to load some test data
when testing the colormap creation -

Now if you are getting so nervous about this, we can load the
test-data in a different way, we'll open up a JIRA for that.  Again,
what you are suggesting is based on a wrong impression because as I
said above:

 - the grid coverage renderer code does NOT depend in anyway on the
arcgrid module, I just use the arcgrid reader to load some test data
when testing the colormap creation -

I hope this time the message gets through!

Simone.

On Wed, Jun 4, 2008 at 4:07 PM, Martin Desruisseaux
<[EMAIL PROTECTED]> wrote:
> Daniele Romagnoli a écrit :
>>
>> +-
>> it.geosolutions.imageio-ext:imageio-ext-arcgrid:jar:1.0-SNAPSHOT:compile
>> |  \-
>> it.geosolutions.imageio-ext:imageio-ext-customstreams:jar:1.0-SNAPSHOT:compile
>
> Yes you are right this is a dependency to the "arcgrid" module of
> "imageio-ext" only, not the GDAL module.
>
> I would be curious to learn why this dependency couldn't be introduced as
> some kind of render plugin (or more likely given the nature of "imageio-ext"
> project, as a coverage I/O plugin), but anyway it is a kind of details to
> us. ("referencing" has similar issue since it has one MathTransform backed
> by JAI Warp - this is again something that I would like to fix later).
>
> Our interest rather lies in the factories for style objects (symbolizer and
> the like - I have not looked at the exact classes since I'm not the one
> working on renderer right now). We do not touch the streaming renderer
> itself. This leads me to the idea about whatever we should split the current
> "render" module in two: some kind of "base-render" to be leveraged by
> various kind of render (including streaming render and the "J2D-renderer"
> currently in progress), and a "streaming-render" with the remaining
> including the arcgrid dependencies (I guess there is no reason for a
> "base-render" module to have a dependency toward a particular image format).
>
> This is just an idea for more though. Such split (if acceptable) is not
> going to happen before a while.
>
>        Martin
>



-- 
-------------------------------------------------------
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

-------------------------------------------------------

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to