[GRASS5] adapting locations to 57, nviz updates

[Helena]

One more issue came up as I was adding WIND3 to my old location and further testing nviz

Separate WIND and WIND3 makes it possible for user to have different horizontal resolution
for 2D and 3D - this sounds pretty incosistent and potentially messy.
However, I can imagine a situation where I want to display high resolution DEM (say 2000x2000)
combined with some isosurfaces generated from 200x200x20 (most of the time the 3D data
density isn't anywhere close to 2D data). To be consistent with the behavior of other
grass modules (and multiple surfaces in nviz) the volume would have to be resampled to
2000x2000x20 if we use a single WIND (which is huge). The volume support allows to select higher polygon size
putting it back to 200x200x20 but is this a desired behavior?

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?

Helena

P.S. While investigating this issue I found bug in the volume support for nviz -
it does not resample when WIND3 is different from the grid3d, putting isosurfaces
into wrong place see:
WIND3:
500m resolution http://skagit.meas.ncsu.edu/~helena/grasswork/zrazky3d.jpg (correct)
250m resolution http://skagit.meas.ncsu.edu/~helena/grasswork/nvizvolresample1.jpg
1000m resolution http://skagit.meas.ncsu.edu/~helena/grasswork/nvizvolresamp2.jpg
Jaro, we will have to talk to Tomas about this





 >> Why WIND and WIND3?!
 >>
 >> Cannot we add top, bottom, depths and t-b resol to WIND? Default (if
 >> not defined)  will be:
 >> top: 1
 >> bottom: 0
 >> depths: 1
 >> t-b resol: 1
 >>
 >> We can add these variables to struct Cell_head and call G_*_window
 >> from G3d_*Window.
 >>
 >> Radim

On Thu, Nov 18, 2004 at 05:30:53PM +0000, Glynn Clements wrote:

 >> The problem here isn't the implementation, but finding all of the
 >> places which need to be changed.
 >>
 >> As well as changing the libgis functions which read and write
 >> Cell_head structures, any code which creates a Cell_head structure
 >> from scratch would need to initialise the vertical fields (top,
 >> bottom, tbres, depths) to sane values.


I am willing to help with the modules (the libraries maybe better not).
The longer we wait the more complicated it may become.


 >> The safest solution would be to revert the NVIZ changes until they are
 >> re-done in such a way that NVIZ is still usable when no WIND3 file
 >> exists.


IMHO this solution would be too conservative.
The new features are really important (for many research areas).

Markus

Jaro Hofierka wrote:
> This would be the best solution. It also needs some notice that vertical 
> reference is needed for 3D modules and nviz.
> 
> Jaro
> 
> Radim Blazek wrote:
> 
>> Why WIND and WIND3?!
>>
>> Cannot we add top, bottom, depths and t-b resol to WIND? Default (if 
>> not defined)  will be:
>> top: 1
>> bottom: 0
>> depths: 1
>> t-b resol: 1
>>
>> We can add these variables to struct Cell_head and call G_*_window 
>> from G3d_*Window.
>>
>> Radim
>>
>>
>> Helena wrote:
>>
>>> Hamish
>>>
>>> I already discussed this issue with Markus but I did not follow up
>>> on the list (as I am trying not to create too many distractions from 
>>> 5.4 release).
>>> Yes, nviz ALWAYS needs WIND3, even if you work just with 2D data.
>>> It is needed to initialize the interface. It will be rather messy to 
>>> have
>>> it start differently for 2D and 3D data.
>>>
>>> This is my suggestion (as there are and will be more modules that 
>>> will require
>>> 3D region)
>>>
>>> >Modify grass57 startup to check and ask for 3D region info.
>>> > What I have in mind is that when you start grass57, it will check for
>>> >WIND3 and if it is not there it will say e.g.:
>>> >This GRASS release is a 3D GIS and requires 3D region definition, do 
>>> you
>>> >want to have it automatically created (you can later modify it using 
>>> g3.region) ? y/n
>>> > then the default WIND3 will just take the current region information
>>> >and define WIND3 with 1 vertical layer.
>>> >If it is done like this we don't have to worry about which module 
>>> requires
>>> >it and we don't need to implement this question into each such module
>>>
>>> Markus, would you have time to implement this modified start-up?
>>> After Paul is done with the release, I suggest that we also revisit 
>>> the vertical
>>> datum issue and creation of a new location under 5.7 as a 3D location 
>>> with 3D window and
>>> a coordinate system definition that includes both horizontal and 
>>> vertical datums.
>>>
>>> Helena
>>
>>
>>
>>
>> _______________________________________________
>> grass5 mailing list
>> grass5 at grass.itc.it
>> http://grass.itc.it/mailman/listinfo/grass5
>>
> 
> 
> -=x=-
> Skontrolovane' antivi'rovy'm programom NOD32
> 
>