Hi all,
I had the chance to inspect this issue, and the results are that the
Band-Select operation seems to be broken.
In other words, the outcome of the band select operation is always a
Coverage that returns back a Rendered Image with a color model null.
If the request forces a coverage scale (like in the GET request
specified in the JIRA comments) or reprojection then a Warp operation
is attached after the band selection restoring the ColorModel.
At this point we need to have a look at GeoTools operation and see
what happen at that level.
Cheers,
Alessio.
On Wed, Jul 23, 2008 at 3:06 AM, Jody Garnett <[EMAIL PROTECTED]> wrote:
> Hi David; well some of the formats people may request require a color
> map. Formats like geotiff should be able to report back generic raster
> goodness; but PNG for example expects RGB. To get you RGB values for
> your PNG encoding will require some kind of ColorTable raster symbolizer
> thing.
>
> What band select take away raster symbolizer must put back. Or you
> should limit the choice of formats to something that does can handle
> single band images (grayscale if you prefer?)
>
> Jody
>
> David Winslow wrote:
>> oops, originally sent this just to Jody.
>>
>> This is using the GeoServer 'release' data; the style for this layer is
>> the default GeoServer 'raster' style.
>> (http://svn.codehaus.org/geoserver/branches/1.7.x/configuration/release/styles/raster.sld)
>>
>> That said, this problem affects WCS GetCoverage requests, so SLD's
>> should not be coming into the equation, as I understand it.
>>
>> -David
>>
>> Jody Garnett wrote:
>>
>>> Hi David; Emily and myself are working on raster symbolizer support in
>>> uDig; and as such we are testing
>>> some of the functionality you describe. We are just starting so I need
>>> to indicate that we don't know much
>>> yet ...
>>> So can I ask what your SLD looks like? It supplies a ColorMap element
>>> etc...
>>>
>>> Jody
>>>
>>>
>>> David Winslow wrote:
>>>
>>>> Hi all,
>>>>
>>>> I've gotten a bit out of my depth in tracking down a bug in GeoServer
>>>> (JIRA issue report is here:
>>>> http://jira.codehaus.org/browse/GEOS-2020) From a debugger session,
>>>> it seems that when GeoServer does band selection on a coverage the
>>>> color model is lost. The code that handles this operation (from
>>>> GeoTools's SelectSampleDimension class) seems to try a couple of ways
>>>> of getting a color model for the result before finally falling back
>>>> to asking the SampleDimension object. In the case of the input
>>>> described in the JIRA issue, the SampleDimension returns null, which
>>>> gets propagated through the rest of the operations and finally causes
>>>> an exception. I'm having trouble working out what the problem is,
>>>> though:
>>>> * Should GeoServer be setting something up differently when reading
>>>> the Coverage in order for the SampleDimension to return a valid color
>>>> model? (If so, it would be nice for the proper reader in GeoTools to
>>>> throw an exception on reading so that cases like this are made
>>>> evident sooner)
>>>> * Should GeoTools have another layer of fallback in determining the
>>>> color model? I'm not very familiar with coverage data/JAI so I don't
>>>> know if this proposal even makes sense.
>>>> * Is there some third, correct answer that I haven't thought of?
>>>>
>>>> Anyway, I'm glad to provide more information about this issue if I
>>>> can. I'm dwins on IRC if you want to reach me there.
>>>>
>>>> -David Winslow
>>>>
>>>> -------------------------------------------------------------------------
>>>>
>>>> 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
>>>> [email protected]
>>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>>>
>>>>
>>> !DSPAM:4040,48866d66207638362916074!
>>>
>>>
>>
>>
>>
>> -------------------------------------------------------------------------
>> 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
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>>
>
>
> -------------------------------------------------------------------------
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/geotools-devel
>
--
-------------------------------------------------------
Eng. Alessio Fabiani
Vice-President /CTO GeoSolutions S.A.S.
Via Carignoni 51
55041 Camaiore (LU)
Italy
phone: +39 0584983027
fax: +39 0584983027
mob: +39 349 8227000
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
