raster

JGrass bases heavily on raster analysis, which introduces the need of some new concepts we will need.

We use raster maps for doing analyses on them they are rendered with some colortable but mainly they are read as numbers there are two mandatory concepts in this that I feel are missing in udig.

active region and resolution

issues by JGrass

1. the active working region is the region on which the raster map will be processed.
   Example: I have a map of 4 gigs an elevation model of whole europe and I want to process only the german part I have to be able to see the whole map but define with a windows the part I'm going to process.
2. the concept of processing resolution
   Example: my 4 gigs map of europe is a 1000x1000 meter cells resolution I want to do processing on the whole map 4 gigs would be too much so I read the map at a lower resolution, example 10000x10000 meters

proposed solutions by UDig

1. Both maps and layers have "Map Blackboards" for plugin collaboration. So rather than try to think of everything every application might want we added Blackboards to each layer and each map plugins can put information on the blackboards that they need for collaboration. (this seems the most probable solution for a first approach)
2. The Vitali Method: as I understand it currently selection is handled on a per layer basis. And is just a filter which is a very generic way of saying what is "selected". Vitali has added a SelectionService to each map which is based on Eclipse's SelectionService but knows about GIS specific information. Also it is extensible for a give application or tool.(this seems to be cool but needs to be explored more indeep)

workflow:

1. define a tool that places your "region" on the black board
2. define opperations that use the "region" to do some processing

GRASS raster format

issues by JGrass
The GRASS format keeps the data matrix compressed (deflate) row by row with a header that keeps row addresses in order to read only the active region so when an operation choses a raster map for processing the map is read with the active region bounds and resolution.

There are various files that form the concept of header:

• the binary file has a byte defining the size of the row address, then the addresses, and finally the zipped rows
• then there are files that keep:
  • the region bounds and resolution of the map file
  • the kind of compression
  • the data type
  • the colortable
  • there is a bitmap file that defines the novalues

GRASS maps can be of type integer, float and double.

PROBLEM:
Consuming JGrass Binary format.

SOLUTION 1
If you have read/write software you don't necessarily need to create a geotools reader/writer you just need to create an adapter from your model to GridCoverage and pass that to the GridCoverageRenderer.

SOLUTION 2
Write a fully-fledged plugin for GeoTools Coverage package

THOUGHTS
The StreamingRenderer uses Coverage Plugins' Readers to create coverages when feeding the GridCoverageRender. It does so by providing an envelope and the requested viewport size to the reader which selects the best availaible resolution depending on the view's resolution and on the capabilities of the underlying format in terms of overviews and/or decimation on reading, as well as tiling. (this is ok for the rendering, but not for what we need most, i.e. datahandling. In that case I define the working resolution on an independent way. Also for high resolution pringing that will be an issue.)
If we go directly to the GridCoverageRenderer no "external" optimization is performed and the provided data is processed. This means no overviews and no decimation.

In this special case (JGrass binary format) we could do subsetting and decimation on the fly at the reader level as well as intelligent tiling. JGRass binary format has stripes like striped geotiff so in the end what you could do is loading only the stripes you need and of each stripe only the needed part possibly with a bit of multithreading (undelrying JAI-ImageIO framework comes with that almost by default)
If we develop a plugin there also are various tricks that we can use to speed things up

• External overviews - we add (it's easy) support for external overviews like in gdal - this requires to preprocess the raster
• Internal pyramid - (not as easy) use an in-memory pyramid, Simboss coded 2 for geotif but never tested enough to release it can be very fast but it is still unstable.
  Of course this approach has a cost in term of time which is not negligible, hence I would recommed it except in the case of qorking under very sstringent deadlines.

If you wrap your architecture behind a GridCoverage2D you might loose some performance gain ( in some cases, with big dataset you would get awful performances) and you might waste a lot of time trying to actually mimic the GridCoverage2D. IMHO the latter solution could be much faster but could also generate some (quite some?) problems
later on. It would great to investigate this path a bit deeper, especially if this integration needs to be done very quickly.

raster rendering

This is also somehow a resume of the format part, they are linked.

proposed solutions by UDig
UDig recomends an "adapter" to GridCoverage; you may also wish to render you raster model directly (it is an option). We don't expect you to do your operations in terms of geotools interfaces.
UDig sees 3 ways to do rendering right now.

1. you can write a geotools reader for your raster format (is a pretty good solution in general but may be some work. Not totally sure on the amount.)
2. you can adapt your Object model to the GridCoverage in geotools (quickest)
3. create a renderer for your raster data/object model which has not geotools dependencies. (lets you do most anything you want But is proabably the most work)