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@stud.fit.vutbr.cz
Web: http://blackhex.no-ip.org
Jabber: blackhex@jabber.cz