[GRASS5] adapting locations to 57, nviz updates

[Helena]

Radim Blazek wrote:
> Helena wrote:
> 
>> 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
> 
> 
> We should start from user point of view: how should it work?
> I think that user expectation is that region extent is
> shared by 2D and 3D raster 3D modules.
> 
> If we follow the 3. option, we probably get even more 'bug'
> reports from users who change the region with d.zoom/g.region,
> r3 module and complain about 'empty' map, because WIND3 is different.
> 
> I believe that 2D and 3D regions must be synchronized and that 2.a)/b) 
> are not real problem.

yes, they need to be synchronized (although that can be done
with separate files too) - I am now trying it out as a user using
Michael's data and I encourage others who have some volume data to do that too,
to get some feeling what is really needed and how it should behave
from the users point of view. I got into the situation with different WIND3 and WIND
right away, so you are right in predicting the troubles, but I am still
worried about changing the WIND file.

Helena
> 
> 2.a) should also change cols3/rows3 using current n-s resol3/e-w resol3 
> (from file) and n,s,e,w from Cell_head and similarly cols/rows if 
> G3D_Region is written
> 
> 
> Radim
> 
> 
> 
>> 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.
>>>
>>
>>
>> _______________________________________________
>> grass5 mailing list
>> grass5 at grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grass5
> 
>