[GRASS-dev] GAL Framework and GRASS rasters

[Glynn Clements]

Radek Bartoň wrote:

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

In retrospect, I can see the point if you have one database for the
whole mapset. The downside is that it complicates sharing mapsets,
although that issue already applies to the attribute database.

> > > 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. :-)

The row argument passed to G_get_raster_row() is converted from the
region's grid to the raster's grid (by compute_window_row in
get_row.c) to determine which row to read from the file.

If the region resolution is coarser than the map's resolution, a
contiguous sequence of region rows will result in a discontiguous
sequences of raster rows.

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

The ability to perform "draft" calculations on huge maps in a
reasonable timeframe is quite important.

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

You can obtain details of function usage with the tools/sql.sh script.

-- 
Glynn Clements <glynn at gclements.plus.com>