[GRASS-dev] [GRASS-SVN] r60054

[Markus Metz]

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