[GRASS-dev] GAL Framework and GRASS rasters

[Radek Bartoň]

Dne Wednesday 24 of October 2007 02:41:41 Glynn Clements napsal(a):

> It might be useful for category attributes (i.e. the way it's used for
> vectors), but I don't think that it makes sense for per-map metadata.

Can you explain why it doesn't make sense in more detail, please? I think that 
using SQLite .db file is not so much complex than any configuration file 
format and it can offer so much better possibilities for implemetation of any 
operation over such metadata. Although another disadvantage is that this 
format is not directly readable. I apply to Matin Landa's presentation about 
lack of metadata support in GRASS.

> > 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.
>
> One of the main issues here is efficiency. The existing mechanism
> means that you don't have to read and decode the entire map if you're
> working at a reduced resolution; any rows which aren't used in the
> scaled-down version are simply skipped.

Of course, this kind of efficiency would have to be considered in that 
hypercube approach too. I ment that by: "specified methods for certain 
warping". User would specify what dimensions, in what resolution, with what 
boundaries in what projection he/she wants and how to deal with "scaling" 
(low pass filter, nearest value, reclass, etc.) by functions context. There 
would need to be implemented advanced cache system and file-based or virtual 
file system disk storage to provide that too.

Can anyone, please, explain me (quickly and on principle) how is done that  
G_get_raster_row() returns raster row at resolution defined by setted window 
efficiently without precomputed pyramids or similar process? I searched for 
that kind of information in GRASS Programmer's Manual but with no luck and 
I'm scared enough to dig out that information form source code. :-)

> Unless you're planning on re-writing much of GRASS from scratch, you
> need to preserve the G_get_raster_row() etc interface. You can have
> other interfaces as well, but the legacy interface must remain for the
> foreseeable future.

Some wrapper for less general interface over more general interface could be 
written anytime. The problem would be efficiency. But there is a question you 
need to answer yourself: Do you want rather top performace with low-level 
approach or do you want scalability and extensibility and catch up 
performance with distributive computation?

> This amounts to a complete re-write. Apart from the vast number of
> static variables (libgis alone has ~180), each library has its own
> context, so e.g. most vector functions would need both a vector
> context and a libgis context; higher-level libraries would need even
> more.

I see, you are not willing to make a radical changes and this is OK for 
correct release engeneering. Can anyone then collect at least list of 
functions which are necessarily needed to preserve and which could be 
deprecated to make picture what can be done with rasters and cause the least 
pain?

-- 
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