[GRASS5] adapting locations to 57, nviz updates

[Helena]

I suggest to follow Glynn's recommendation and preserve the WIND and WIND3
as separate files. I just got the bug fix from Tomas as well as
an addition of g3.createwind b=0 t=1 dres=1 to nviz if neither
WIND3 nor DEFAULTWIND3 is found. I will test it and if it works
well for the old locations I will submitt it as soon as possible.
We still need an update for grass57 startup with new locations
to make the user define DEFAULTWIND3 (or accept some defualt).
Also, vertical datum needs to be added to PROJ (even if we do not
support any vertical datum transformations).

Helena

Glynn Clements wrote:
> 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.
>