Re: [technology-pmc] Seeking exempt status JAI and ImageIO dependencies

[Jody Garnett <jody.garnett@xxxxxxxxx>]

On Thu, Aug 22, 2013 at 1:34 AM, Wayne Beaton <wayne@xxxxxxxxxxx> wrote:

Is it the intent to pursue this as an "exempt pre-req" dependency on the basis that we can reasonably expect that it is already installed on the workstations of the sort of user who will use UDig?

That is not the intent. We expect to ship these dependencies with the application.

We had listed "installation of JAI" as a prerequisite for uDig 1.0 and were swamped with installation questions. Keep in mind that our target audience is a "gis professional" rather than a "developer". These user-friendly way to manage JAI turns out to be java webstart , something that eclipse RCP applications can work with now, but could not do so initially.

Or is it a "works with" dependency that exposes enhanced functionality in UDig when present?

This is a "exempt pre-req" it is required for uDig to get out of bed in the morning.

At a technical level the raster handling facilities of Java 2D and SWT require loading an entire image into memory. For GIS sized raster data this situation (even on modern computers) is not feasible. GIS raster data is simply too big - and a more sophisticated approach is required.

The other criteria is the ability to support ad-hoc process of raster data. I am less technically versed in this area, the operations I understand are:

- coordinate system transformation - set up a reverse transformation and sample from the intended result pixels back through the processing chain to the original data sources, pulling the data through the chain applying any styling or channel manipulation along the way.

- digital elevation models: treating the raster data as a height measurement allows a lot of great techniques such as view shed analysis (I can see my house from here) and hydrology (water flows downhill).  

- Note that two processing chains are required, one to focus on a visual result, and a second to preserve values exactly when handling scientific measurements (such as height).

Alternatives evaluated:

- SWT Advanced Graphics: I was quite keen when SWT announced "advanced graphics" for SWT 3.1 - however on closer inspection it only offered "path for curves and lines, alpha blending and transformations". Evaluation: Large raster data would be taken into memory, unsuitable for GIS work.

- OpenGL: There is a long history of OpenGL use in Eclipse RCP apps. Unfortunately this only helps with the efficient display of raster data. The remaining infrastructure required to smoothly load resources off disk (required for large GIS data) and support ad-hoc processing (required to make this a Geogrpahic Information System rather than a geospatial display) is always left as an exercise for the reader. Finally OpenGL is heavily focused on visual display, with graphics cards often taking amusing short cuts to get a faster draw rate - this is in conflict with handling our data carefully when directly working with measurements (such as height). 

- C++ Libraries: As mentioned previously there is a range of C++ libraries in this space - as an example OSSIM. We did an out reach effort with the OSSIM team in 1995 after meeting their sponsor at a FOSS4G conference.

--

Jody