[GRASS5] adapting locations to 57, nviz updates

[Glynn Clements]

Radim Blazek wrote:

> > So does anybody see a compelling reason to keep 3D region (including 
> > resolution) independent
> > from 2D region or should they be the same (merged in a single WIND) and 
> > any relevant resolution issues
> > should be handled by modules?
> > Glynn, how does r3.mapcalc handle situation when the region defined in 
> > WIND3 has different resolution
> > from the 3d raster(s) used in mapcalc - is there 3d resampling?
> 
> It sounds reasonable to have different resolutions for 2D and 3D,
> However, it can be still in the same file. n,s,e,w can be
> the same and only the resolution will be different.
> We could also add a 3D/2D resolution ratio, so that
> changing 2D resolution will automaticaly change also 3D resolution
> if not specified.

As I see it, there are three options:

1. Merge both the files (WIND, WIND3, cellhd/*) and the structures
("struct Cell_head" and G3D_Region).

2. Merge the files but have separate structures.

3. Preserve the status quo, i.e. have separate files.

The problem with option 1 is that any programs which directly
manipulate the fields of a "struct Cell_head" may need to be changed
to account for the new fields.

The problems with option 2 are that:

a) writing a 2D region (i.e. G__write_Cell_head()) would involve
reading in the existing 3D data, replacing the 2D component, then
writing it back out (rather than just overwriting the WIND file), and

b) reading a 3D region would involve inserting default values for the
vertical axis in the event that the WIND file only contains 2D
settings.

The problem with the third option is that NVIZ now requires a WIND3
file even if you don't use the g3d stuff, and most users won't have a
WIND3 file and don't know what a WIND3 file is or how to create it.

To implement, 1 is the hardest, 3 is the easiest.

My preference would be option 3, with some steps to simplify
transition (e.g. the code which creates locations and mapsets would
create the 3D files as well as the 2D files).

Failing that, option 2 has the advantage that there are a limited
number of places (in libgis and libg3d) which need to be changed.

Option 1 is one of those situations where we'll spend the next couple
of years receiving the occasional bug report about the cases which
nobody noticed in the first instance.

-- 
Glynn Clements <glynn at gclements.plus.com>