[GRASS5] nviz problems

GRASS GIS GRASS GIS developer
1

Dear all,
I have just updated the 57 CVS and I have just tried to start NVIZ...
I have a problem because NVIZ doesn't start and I obtain this message:
______________________________________________________________________
WARNING: G3d_readWindow: unable to find
         [//home/ivan/DATABASEGRASS/gauss_boagaEST/moreno/WIND3], using
default.
WARNING: G3d_readWindow: unable to find
        
[//home/ivan/DATABASEGRASS/gauss_boagaEST/PERMANENT/DEFAULT_WIND3].
FATAL ERROR: G3d_initDefaults: Error reading window
child process exited abnormally
    while executing
"exec /usr/local/grass-5.7.cvs/etc/nviz2.2/NVWISH2.2 -f
/usr/local/grass-5.7.cvs/etc/nviz2.2/scripts/nviz2.2_script -q -name
NVIZ >&@stdout"
    ("eval" body line 1)
    invoked from within
"eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f
$env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script $argv -name NVIZ

&@stdout"

    invoked from within
"if {$argv == ""} {
#no arguments
eval exec $env(GISBASE)/etc/nviz2.2/NVWISH2.2 -f
$env(GISBASE)/etc/nviz2.2/scripts/nviz2.2_script -name NVIZ >&@stdo..."
    (file "/usr/local/grass-5.7.cvs/bin/nviz" line 16)
___________________________________________________________________________

can you help me to solve the problem???
thanks

Ivan

2

ivan marchesini wrote:

I have just updated the 57 CVS and I have just tried to start NVIZ...
I have a problem because NVIZ doesn't start and I obtain this message:
______________________________________________________________________
WARNING: G3d_readWindow: unable to find
         [//home/ivan/DATABASEGRASS/gauss_boagaEST/moreno/WIND3], using
default.
WARNING: G3d_readWindow: unable to find
        
[//home/ivan/DATABASEGRASS/gauss_boagaEST/PERMANENT/DEFAULT_WIND3].
FATAL ERROR: G3d_initDefaults: Error reading window

Use g3.createwind to create the WIND3 file. It shouldn't matter what
values you choose for the Z axis so long as you don't actually use the
G3D (3D voxel grids) features.

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

3

> I have just updated the 57 CVS and I have just tried to start
> NVIZ... I have a problem because NVIZ doesn't start and I obtain
> this message:

..

> WARNING: G3d_readWindow: unable to find
> [//home/ivan/DATABASEGRASS/gauss_boagaEST/moreno/WIND3],
> using
> default.
> WARNING: G3d_readWindow: unable to find
>
> [//home/ivan/DATABASEGRASS/gauss_boagaEST/PERMANENT/DEFAULT_WIND3].
> FATAL ERROR: G3d_initDefaults: Error reading window

Use g3.createwind to create the WIND3 file. It shouldn't matter what
values you choose for the Z axis so long as you don't actually use the
G3D (3D voxel grids) features.

This is a more general problem with the latest NVIZ vol updates.

You get this error even if you do 'nviz -q' in a new mapset.

Either we have to generate WIND3 files with each new mapset or
(preferably) conditionalize the G3d_initDefaults() call for when it
is really needed.

Hamish

4

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

  wrote:

I have just updated the 57 CVS and I have just tried to start
NVIZ... I have a problem because NVIZ doesn't start and I obtain
this message:

..

WARNING: G3d_readWindow: unable to find
        [//home/ivan/DATABASEGRASS/gauss_boagaEST/moreno/WIND3],
        using
default.
WARNING: G3d_readWindow: unable to find
       [//home/ivan/DATABASEGRASS/gauss_boagaEST/PERMANENT/DEFAULT_WIND3].
FATAL ERROR: G3d_initDefaults: Error reading window

Use g3.createwind to create the WIND3 file. It shouldn't matter what
values you choose for the Z axis so long as you don't actually use the
G3D (3D voxel grids) features.

This is a more general problem with the latest NVIZ vol updates.

You get this error even if you do 'nviz -q' in a new mapset.

Either we have to generate WIND3 files with each new mapset or
(preferably) conditionalize the G3d_initDefaults() call for when it is really needed.

Hamish

_______________________________________________
grass5 mailing list
grass5@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

5

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

6

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@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

-=x=-
Skontrolované antivírovým programom NOD32

7

It would certainly be much less confusing for the users to have
a single WIND file both for 2D and 3D. I am all for it unless
it requires a lot of changes that nobody has time to do.
This would be a significnat change - what do others think about it?
Are there any significant problems that this would cause that we haven't
thought about?

thanks,

Helena

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

8

On Sun, Nov 07, 2004 at 09:55:00PM -0500, Helena wrote:

It would certainly be much less confusing for the users to have
a single WIND file both for 2D and 3D. I am all for it unless
it requires a lot of changes that nobody has time to do.

IMHO it's the only way to avoid that we upset all GRASS users
(including ourselves). To change many, many locations I am not
really interested in. Let's try the suggested approach which
should be backward compatible to older locations.

This would be a significnat change - what do others think about it?

I feel from a user's point of view that it is less significant than
having to change all my locations.

Are there any significant problems that this would cause that we haven't
thought about?

Worth a try - we are in CVS HEAD, so we can try that. And it should
be done before releasing 6.0.

Markus

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
>
>
>

9

Helena,

My opinion shouldn't count as much as those who know what might be involved
in modifying other applications. But for my 2 cents worth this seems like
the best option by far. If GRASS is going to generally support 3D (and I
very much hope it continues to go this way) a single WIND file makes much
more sense than 2 separate ones.

Michael

On 11/7/04 7:55 PM, "Helena" <hmitaso@unity.ncsu.edu> wrote:

It would certainly be much less confusing for the users to have
a single WIND file both for 2D and 3D. I am all for it unless
it requires a lot of changes that nobody has time to do.
This would be a significnat change - what do others think about it?
Are there any significant problems that this would cause that we haven't
thought about?

thanks,

Helena

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

______________________________
Michael Barton, Professor of Anthropology
School of Human, Evolution and Social Change
Arizona State University
Tempe, AZ 85287-2402
USA

voice: 480-965-6262; fax: 480-965-7671
www: http://www.public.asu.edu/~cmbarton

10

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@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

-=x=-
Skontrolovane' antivi'rovy'm programom NOD32

11

Helena wrote:

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?

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.

For example
g.region res2to3=0.1
g.region res=100 => res=100 res3=1000
g.region res=100 res3=100 => res=100 res3=100

Radim

12

Helena wrote:

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?

I don't know. It uses G3d_getValueRegion(); is that in the region's
coordinates or the map's coordinates? The g3d documentation isn't
exactly clear.

It *should* be resampling the data; if it isn't, then I need to use
G3d_getValue() instead.

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

13

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@gclements.plus.com>

14

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.

15

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@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5

16

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@grass.itc.it
http://grass.itc.it/mailman/listinfo/grass5