A Process will take care of rendering a coverage on top of a specified colorMap.
Such a ColorMap will be “Dynamic” since the processing code will adapt the colors to the actual values range of a layer (through a linear stretch) keeping, as an instance, MIN layer value = BLUE and MAX layer value = RED.
Moreover, previously computed statistical metadata through gdalinfo are supported and may be exposed through a RenderingTransformation to retrieve the range. (Gdalinfo auxiliary metadata parsing has been already supported on GeoTools ImageMosaic: See linked JIRA on GEOS-6184).
colormaps may be defined:
as a list of explicit RGB values (In that case, the colors will be equidistant along the range)
Finally, a dispatcherCallback will be defined to intercept a getLegendGraphics involving a renderingTransformation based on that process. It will dynamically setup the legend for the specific layer (also parsing any dimension provided in the request, such as time, elevation, … since statistics change across different slices of a multidimensional coverage).
I would like to contribute that module to the community.
A Process will take care of rendering a coverage on top of a specified colorMap.
Such a ColorMap will be “Dynamic” since the processing code will adapt the colors to the actual values range of a layer (through a linear stretch) keeping, as an instance, MIN layer value = BLUE and MAX layer value = RED.
Moreover, previously computed statistical metadata through gdalinfo are supported and may be exposed through a RenderingTransformation to retrieve the range. (Gdalinfo auxiliary metadata parsing has been already supported on GeoTools ImageMosaic: See linked JIRA on GEOS-6184).
colormaps may be defined:
as a list of explicit RGB values (In that case, the colors will be equidistant along the range)
Finally, a dispatcherCallback will be defined to intercept a getLegendGraphics involving a renderingTransformation based on that process. It will dynamically setup the legend for the specific layer (also parsing any dimension provided in the request, such as time, elevation, … since statistics change across different slices of a multidimensional coverage).
I would like to contribute that module to the community.
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
Ciao Daniele,
being a community module I guess that my +1 should be enough.
I would recommend to write down some document upfront.
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
A Process will take care of rendering a coverage on top of a specified colorMap.
Such a ColorMap will be “Dynamic” since the processing code will adapt the colors to the actual values range of a layer (through a linear stretch) keeping, as an instance, MIN layer value = BLUE and MAX layer value = RED.
Moreover, previously computed statistical metadata through gdalinfo are supported and may be exposed through a RenderingTransformation to retrieve the range. (Gdalinfo auxiliary metadata parsing has been already supported on GeoTools ImageMosaic: See linked JIRA on GEOS-6184).
colormaps may be defined:
as a list of explicit RGB values (In that case, the colors will be equidistant along the range)
Finally, a dispatcherCallback will be defined to intercept a getLegendGraphics involving a renderingTransformation based on that process. It will dynamically setup the legend for the specific layer (also parsing any dimension provided in the request, such as time, elevation, … since statistics change across different slices of a multidimensional coverage).
I would like to contribute that module to the community.
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
Ciao Daniele,
being a community module I guess that my +1 should be enough.
I would recommend to write down some document upfront.
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
A Process will take care of rendering a coverage on top of a specified colorMap.
Such a ColorMap will be “Dynamic” since the processing code will adapt the colors to the actual values range of a layer (through a linear stretch) keeping, as an instance, MIN layer value = BLUE and MAX layer value = RED.
Moreover, previously computed statistical metadata through gdalinfo are supported and may be exposed through a RenderingTransformation to retrieve the range. (Gdalinfo auxiliary metadata parsing has been already supported on GeoTools ImageMosaic: See linked JIRA on GEOS-6184).
colormaps may be defined:
as a list of explicit RGB values (In that case, the colors will be equidistant along the range)
Finally, a dispatcherCallback will be defined to intercept a getLegendGraphics involving a renderingTransformation based on that process. It will dynamically setup the legend for the specific layer (also parsing any dimension provided in the request, such as time, elevation, … since statistics change across different slices of a multidimensional coverage).
I would like to contribute that module to the community.
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
For the getLegendGraphic part I make use of some utility methods and objects from wms (org.geoserver.wms.legendgraphic.Cell and org.geoserver.wms.legendgraphic.ColorMapLegendCreator) which are package private classes.
Instead of copying and modifying them as per my needs on the community module, I would like to make them public on the wms module so that they can be used from other modules.
Does it make sense? In that case, what is the required procedure to make them public?
A Process will take care of rendering a coverage on top of a specified colorMap.
Such a ColorMap will be “Dynamic” since the processing code will adapt the colors to the actual values range of a layer (through a linear stretch) keeping, as an instance, MIN layer value = BLUE and MAX layer value = RED.
Moreover, previously computed statistical metadata through gdalinfo are supported and may be exposed through a RenderingTransformation to retrieve the range. (Gdalinfo auxiliary metadata parsing has been already supported on GeoTools ImageMosaic: See linked JIRA on GEOS-6184).
colormaps may be defined:
as a list of explicit RGB values (In that case, the colors will be equidistant along the range)
Finally, a dispatcherCallback will be defined to intercept a getLegendGraphics involving a renderingTransformation based on that process. It will dynamically setup the legend for the specific layer (also parsing any dimension provided in the request, such as time, elevation, … since statistics change across different slices of a multidimensional coverage).
I would like to contribute that module to the community.
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk
On Fri, Jan 17, 2014 at 12:34 PM, Daniele Romagnoli <
daniele.romagnoli@anonymised.com> wrote:
Question on that topic:
For the getLegendGraphic part I make use of some utility methods and
objects from wms (org.geoserver.wms.legendgraphic.Cell and
org.geoserver.wms.legendgraphic.ColorMapLegendCreator) which are package
private classes.
Instead of copying and modifying them as per my needs on the community
module, I would like to make them public on the wms module so that they can
be used from other modules.
Does it make sense? In that case, what is the required procedure to make
them public?
Those classes were written by Simone. I cannot see a reason to keep them
package private if they are needed in another module, but maybe
double check with him.
If it's ok, I'd just go ahead and commit the visibility change
For the getLegendGraphic part I make use of some utility methods and objects from wms (org.geoserver.wms.legendgraphic.Cell and org.geoserver.wms.legendgraphic.ColorMapLegendCreator) which are package private classes.
Instead of copying and modifying them as per my needs on the community module, I would like to make them public on the wms module so that they can be used from other modules.
Does it make sense? In that case, what is the required procedure to make them public?
Those classes were written by Simone. I cannot see a reason to keep them package private if they are needed in another module, but maybe
double check with him.
If it’s ok, I’d just go ahead and commit the visibility change
I wonder of the colorbrewer stuff could join the colormap module when it eventually becomes an extension. It would be nice to have a “gt-color” extension to gather up similar concerns.
For the getLegendGraphic part I make use of some utility methods and objects from wms (org.geoserver.wms.legendgraphic.Cell and org.geoserver.wms.legendgraphic.ColorMapLegendCreator) which are package private classes.
Instead of copying and modifying them as per my needs on the community module, I would like to make them public on the wms module so that they can be used from other modules.
Does it make sense? In that case, what is the required procedure to make them public?
Those classes were written by Simone. I cannot see a reason to keep them package private if they are needed in another module, but maybe
double check with him.
If it’s ok, I’d just go ahead and commit the visibility change
