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 <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list grass-dev@grass.itc.it http://grass.itc.it/mailman/listinfo/grass-dev
