Add convenience method for constructing a GridCoverage from a matrix

Description

Currently, users can construct a GridCoverage in three different ways:

  • From a RenderedImage: painfull for most users.

  • From a WritableRaster: easier once we know which class to use,
    but users lost a lot of time finding their way through the API.

  • From an ImageFunction: few use it.

An easier way is needed. User should be able to construct a GridCoverage right from a matrix, for example a float[][]. Problem to solves first:

  • Which signature? float[][] or float[] with a "linelength" argument?
    Note that float[][] will require to copy the data, while the copy
    may be avoided with the float[] argument.

  • Do we add convenience methods for all primitive types?
    (boolean[][], byte[][], short[][], int[][], float[][], double[][])
    Techically not a problem, but add a lot of method signatures.

  • Others arguments are available (CoordinateSystem, Envelope,
    min/max values, units, color map, properties, etc.). Which
    one do we provides? Which one to compute a default value?

  • Where to put the convenience methods? As GridCoverage
    constructors? It could add many of those. In some new
    GridCoverageFactory class?

Environment

None

Activity

Show:
codehaus
April 10, 2015, 2:55 PM

CodeHaus Comment From: aaime - Time: Tue, 20 Jan 2004 04:14:11 -0600
---------------------
EXTERNAL MESSAGE:

SUBJECT: Re: [Geotools-devel] [jira] Created: (<a href="https://jira.codehaus.org/browse/GEOT-63" title="Add convenience method for constructing a GridCoverage from a matrix" class="issue-link" data-issue-key="GEOT-63"><strike>GEOT-63</strike></a>) Add convenience method

&nbsp;for constructing a GridCoverage from a matrix

&gt; An easier way is needed. User should be able to construct a

&gt; GridCoverage right from a matrix, for example a float[][]. Problem to

&gt; solves first:

&gt;

&gt; - Which signature? float[][] or float[] with a &quot;linelength&quot; argument?

&gt; Note that float[][] will require to copy the data, while the copy

&gt; may be avoided with the float[] argument.

Both, with a warning on the fact the the copying is needed so there&#39;s

a memory and performance cost to pay (and modifying the original matrix

won&#39;t affect the GridCoverage).

&gt; - Do we add convenience methods for all primitive types?

&gt; (boolean[][], byte[][], short[][], int[][], float[][], double[][])

&gt; Techically not a problem, but add a lot of method signatures.

Yes, for all.

&gt; - Others arguments are available (CoordinateSystem, Envelope, min/max

&gt; values, units, color map, properties, etc.). Which one do we

&gt; provides? Which one to compute a default value?

&gt;

&gt; - Where to put the convenience methods? As GridCoverage constructors?

&gt; It could add many of those. In some new GridCoverageFactory class?

Why don&#39;t we create a factory to get a WritableRaster out of various

possible inputs, and leave GridCoverage as it is? This way we split

the convenience methods needed to create a WritableRaster and the ones

needed to easily manage the cs, sampledimension, and so on.

WritableRasterFactory would have methods to:

  • create empty WritableRaster (thus, wrapping the jai RasterFactory);

  • create from typex[][] with copying;

  • create from typex[] by wrapping;

Oh, what about multiple bands?

This would allow to have a two/three step process to create a GridCoverage:

  • create the cs (optional)

  • create the writableraster

  • create the gridCoverage

codehaus
April 10, 2015, 2:55 PM

CodeHaus Comment From: desruisseaux - Time: Fri, 1 Feb 2008 04:50:31 -0600
---------------------
The GridCoverageFactory class provides a set of convenience methods. More can be added as the need arise.

Assignee

Unassigned

Reporter

codehaus

Triage

None

Components

Fix versions

Affects versions

Priority

Medium
Configure