Radek Bartoň wrote: > > 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.
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. > 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. 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. > 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. 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. > 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. 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. -- Glynn Clements <[EMAIL PROTECTED]> _______________________________________________ grass-dev mailing list [email protected] http://grass.itc.it/mailman/listinfo/grass-dev
