[GRASS-dev] GAL Framework and GRASS rasters
glynn at gclements.plus.com
Sun Oct 28 22:46:05 CET 2007
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
You can obtain details of function usage with the tools/sql.sh script.
Glynn Clements <glynn at gclements.plus.com>
More information about the grass-dev