Glynn Clements wrote: > > Huidae Cho wrote: > >> But again, when they call fatal error internally, they don't have pointers >> to maps. It would be great if we could keep track of opened raster/vector >> maps and properly close existing maps and delete unfinished new maps inside >> G_fatal_error. And use G_add_error_handler to do a non-map related cleanup. > > Right. > > Anything related to raster maps is available through the R__ structure > in lib/raster (R.h, init.c). R__.fileinfo is an array of "fileinfo" > structures, with R__.fileinfo_count elements. The open_mode field of > each structure will be -1 for unused slots, or one of the OPEN_* > constants (1, 2, or 3) for an open map. > > I'm not that familiar with the vector library, but it looks like > everything relating to a map is stored in a Map_info structure which > is passed in by the caller. There's no global table of vector maps, > right?
No. But such a list of opened maps sounds like a good idea. > > If so, I suggest changing that, however invasive it may be. Very invasive. > I'd > certainly suggest holding off on any 7.0 release until that's > resolved. Hmm. This sounds like synchronizing some basic concepts of the raster and vector libraries, which in turn sounds like something for GRASS 8. GRASS 7 is IMHO in pretty good shape right now, lots of new features, faster, global LFS, etc. And GRASS 7 is not new, it is actually many years old. Therefore I would rather like to see get 7 released soon and synchronize raster and vector libs in GRASS 8. For example, something I am really missing in GRASS raster data is the history of GRASS vector data. Also some more raster metadata like number of non-null cells, mean and stddev (see GDAL) would be really helpful. Not to mention the organization of raster file storage: have one raster folder like for vector. Markus M _______________________________________________ grass-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/grass-dev
