[GRASS-dev] GAL Framework and GRASS rasters

[Radek Bartoň]

Dne Tuesday 23 of October 2007 21:53:27 Hamish napsal(a):
> I would say discuss ideas on the mailing list then summarize discussion on
> the wiki. Otherwise there is no discussion, just the last person to edit
> the wiki page sets the (supposed) direction. Also ideas get much wider
> exposure on the mailing list in the short term.

OK, here are some ideas then:

1. In reply to discussion about metadata:

What about to store all metadata of raster layer in single database instead of 
in XML or other files. It don't have to be full-featured DBMS like 
PostgreSQL. Using single file with SQLite database would be for this purpose 
enough and I think that most suitable.

Pros and cons:

+	Better performance for greater number of layers and metadata.
- 	Worse performance for lesser nuber of layers and metadata.
+	Easy way for implementation of metadata searching or similar operations.
-	Metadata are separated from data in case you want to transfer layers from 
one environment to another directly.

2. In reply to discussion about 3D rasters and time series.

What about to approach rasters like 1-N dimensional "Rubik's" cubes? There 
would be specified methods for certain dimension swapping, warping using 
certain functions like sumarization, average, clipping, and it would be up to 
library user to decide what each of dimensions mean.

3. In reply to pyramids vs. tiles discussion:

I think we should specify raster library API first, so we define what we want 
to achieve, and think about certain aspects of implementation lately. Of 
course it won't be that simple as it sounds and it would need some portion of 
programming experience to handle this but, I think, that in this case this 
should be transparent because library user would want to get some area of 
raster data and won't care how they are organized internally.

On the other hand different approaches are suitable for different tasks. In 
this case, for example, is tile based structure more suitable for computing 
in rasters and pyramids are more suitable for data visualisation on Web or in 
3D. I think that core API should be implementation independent but there 
should be defined some sort of extension mechanism too (like i. e. in 
OpenGL). Such an extension would then approach rasters like tiles and there 
would be other extension which would make a quad tree structure over tiles 
for pyramids support.

4. About function singature format:

If we stick into function sigature format like:

int G_function_name(<structure> * context, <argument>, <argument>, ..., 
<out_argument>, <out_argument>, ...);

when return value is a error code and first argument is a pointer to structure 
carrying information about context (mapset, layer, etc.), it would be easier 
to implement reentrance of such functions and bindings of API to object 
oriented laguages like C++ or Pytion although SWIG would need special note 
about output arguments in interface files.

Please comment this ideas, but please don't eat me alive. :-)

-- 
Bc. Radek Bartoň

Faculty of Information Technology
Brno University of Technology

E-mail: xbarto33 at stud.fit.vutbr.cz
Web: http://blackhex.no-ip.org
Jabber: blackhex at jabber.cz