[GRASS5] adapting locations to 57, nviz updates

[Radim Blazek]

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.

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