[GRASS5] g3d notes and possible bugs

[Alfonso_Vitti]

Hi all, Happy New Year

On Wed, 2003-01-08 at 12:01, John Harrop <johnh@sjgeophysics.com> wrote:

Message: 1
Date: Thu, 02 Jan 2003 17:32:28 -0800
From: John Harrop <johnh@sjgeophysics.com>
Reply-To: johnh@sjgeophysics.com
Organization: SJ Geophysics Ltd / Cyberquest Geoscience Ltd
To: grass-dev <grass5@grass.itc.it>
Subject: [GRASS5] g3d notes and possible bugs

Hello and Happy New Year,

I've been away from the g3d work for a while on less interesting stuff
(grant applications, hiring co-op students etc but I've now had a
chance to try out the revisions made by AV - particularly in r3.out.v5d

We have been running production data through the system partly for a
presentation tomorrow, but also to get ready for a trade show (Mineral
Exploration and Mining) later this month in Vancouver, Canada. We will
be high-lighting Grass and related tools at our booth. The block of
(real) data I've been working with unfortunately has topographical
features that as as close to N-S as makes no difference! This resulted
in lots of fun trying to check if the N-S axis was being reversed!

sorry but I didn't understand well, do you mean that you have N-S
symmetrical data? and that (since the follows) "Y (northing)" is
reversed?

1) We can confirm that work done by AV in r3.out.v5d has fixed the
problem with non-square (x dim = y dim) grid3s being exported
incorrectly. r3.showdspf and vis5d now have equivalent display.

2) The Gmakefile for r3.showdspf.openGL in 5.0.0 exp is missing -lGLw
and -lXm in the OGLLIB line. This has been fixed in the release source,
but not in the exp.

I can tell nothing about the Gmakefile file.
I'm running:
GRASS-5.0_exp_2002_11_08 and
GRASS-5.0.0
and in no one of the two r3.showdspf.openGL/Gmakefile there are -lGLw
and -lXm in the OGLLIB line.

3) Importing 2d elevation data does not result in the same display as
importing equivalent data with a 3d site approach. I'm fairly sure the
fault lies in s.vol.idw - (yes, I know it was recommended that we use
s.vol.rst, but I have yet to get the 3d one to run without crashing.)
For a smooth 3d block model the idw approach is good enough for
testing. Both Z (elevation) and Y (northing) are reversed when
displayed after importing. With the storage order being the reverse of
physical coordinates for Y and Z its not hard to accidentally reverse
the storage in a loop. I think AV may have done two fixes in the code
that cancelled each other I'll check that in more detail and report
later.

ok, you've discovered me the fixes done in s.vol.idw/main.c
cancelled each other. This is becouse when I checked the code it alrady
worked, but the row-for_loop was not consisting with the ones in the
others r3.* modules. In fact the following is the way the r3
row-for_loop work:

for (row = nofrows; row >= 0; row--)

which was different from the one in s.vol.idw/main.c so I decided to
write it like all the others.

In the r3.* modules and in the G3d library there is a bit of confusion
with rows-cols and x-y notation and the notation iself is not always the
same of 2d modules, and this could be the reason for which Z (elevation)
and Y (northing) are reversed. I'm working (not to hard actually) on
this, but I don't have tried all the modules with real asymmetrical
data. sorry 'bout that

4) r3.mask is crashing as follows:

> r3.mask maskvalues=-1 grid3=test.20-t
> FATAL ERROR: G3d_getDoubleRegion: error in G3d_getTilePtr

I don't know, I can check too

I have not had a chance to start exploring the error message. It may be
a bug in the operator. Since I have not been able to create a 3d mask,
so that may be why s.vol.rst is failing and complaining about too few
points?

I have not entered any of these as bug reports because I'm actively
working on them, and in the spirit of Open Source hopefully I'll have a
fix to post with the bug!

Cheers,

John Harrop

Best regards
  
  Alfonso Vitti

[Eric_G_Miller]

On Wed, Jan 08, 2003 at 03:24:21PM +0100, Alfonso Vitti wrote:

> 2) The Gmakefile for r3.showdspf.openGL in 5.0.0 exp is missing -lGLw
> and -lXm in the OGLLIB line. This has been fixed in the release source,
> but not in the exp.

I can tell nothing about the Gmakefile file.
I'm running:
GRASS-5.0_exp_2002_11_08 and
GRASS-5.0.0
and in no one of the two r3.showdspf.openGL/Gmakefile there are -lGLw
and -lXm in the OGLLIB line.

Perhaps not, but they used to be added in the configure scripts
specifically for this program. Since it's such a hacky program and
since the r3 stuff has this coordinate axes confusion, it was all
"dropped" from standard grass builds until the problems could be
fixed. Hence, the GL widgets and motif checks disappeared from
configure.in.

--
echo ">gra.fcw@2ztr< eryyvZ .T pveR" | rot13 | reverse

[Glynn_Clements]

Eric G. Miller wrote:

> > 2) The Gmakefile for r3.showdspf.openGL in 5.0.0 exp is missing -lGLw
> > and -lXm in the OGLLIB line. This has been fixed in the release source,
> > but not in the exp.
>
> I can tell nothing about the Gmakefile file.
> I'm running:
> GRASS-5.0_exp_2002_11_08 and
> GRASS-5.0.0
> and in no one of the two r3.showdspf.openGL/Gmakefile there are -lGLw
> and -lXm in the OGLLIB line.

Perhaps not, but they used to be added in the configure scripts
specifically for this program. Since it's such a hacky program and
since the r3 stuff has this coordinate axes confusion, it was all
"dropped" from standard grass builds until the problems could be
fixed. Hence, the GL widgets and motif checks disappeared from
configure.in.

Actually, the checks are there, but you have to explicitly choose
--with-glw and --with-motif (both are disabled by default).

The relevant make variables are:

XMINC
XMLIB
OPENGLwINC
LGLWM

AFAICT, the correct usage is:

EXTRA_CFLAGS = $(OPENGLwINC) $(OPENGLINC) $(XMINC) $(XCFLAGS)

OGLLIB = $(LGLWM) $(OPENGLULIB) $(OPENGLLIB) $(XLIBPATH) $(XMLIB) $(XTLIB) $(XLIB) $(XEXTRALIBS)

--
Glynn Clements <glynn.clements@virgin.net>

[John_Harrop]

Alfonso Vitti wrote:

We have been running production data through the system partly for a presentation tomorrow, but also to get ready for a trade show (Mineral Exploration and Mining) later this month in Vancouver, Canada. We will be high-lighting Grass and related tools at our booth. The block of (real) data I've been working with unfortunately has topographical features that as as close to N-S as makes no difference! This resulted in lots of fun trying to check if the N-S axis was being reversed!
   
sorry but I didn't understand well, do you mean that you have N-S
symmetrical data? and that (since the follows) "Y (northing)" is
reversed?

Correct. The topography is remarkably N-S symetrical, and while the reversal in elevation-depth was immediately obvious the N-S reversal was not - until I started looking at the sub-surface model.

3) Importing 2d elevation data does not result in the same display as importing equivalent data with a 3d site approach. I'm fairly sure the fault lies in s.vol.idw - (yes, I know it was recommended that we use s.vol.rst, but I have yet to get the 3d one to run without crashing.) For a smooth 3d block model the idw approach is good enough for testing. Both Z (elevation) and Y (northing) are reversed when displayed after importing. With the storage order being the reverse of physical coordinates for Y and Z its not hard to accidentally reverse the storage in a loop. I think AV may have done two fixes in the code that cancelled each other I'll check that in more detail and report later.
   

ok, you've discovered me the fixes done in s.vol.idw/main.c
cancelled each other. This is becouse when I checked the code it alrady
worked, but the row-for_loop was not consisting with the ones in the
others r3.* modules. In fact the following is the way the r3
row-for_loop work:

for (row = nofrows; row >= 0; row--)

which was different from the one in s.vol.idw/main.c so I decided to
write it like all the others.

In the r3.* modules and in the G3d library there is a bit of confusion
with rows-cols and x-y notation and the notation iself is not always the
same of 2d modules, and this could be the reason for which Z (elevation)
and Y (northing) are reversed. I'm working (not to hard actually) on
this, but I don't have tried all the modules with real asymmetrical
data. sorry 'bout that

(I posted some notes I made over Christmas/New Years to the user list - I'll repost them on the dev list so we keep this thread in the same archive.)

I think the g3d modules are very close to working. The work you did has fixed many of the problems - a particularly important fix was getting the read and write working consistently. I suspect that what remains is primarily getting the x,y,z (col,row,depth) loops working consistently. We are starting to use these modules with real data. We can view this data using different tools, so there are some good external checks available. We also load some of the data into the 2D components of grass, and that is providing a good check with that part of the system.

If I understand MN correctly, the STORAGE order should be W->E, N->S, T->B. The first two of these result in 'compatability' with 2D grass. This results in a depth-major storage. Since the index mapping in the read/write functons keeps x,y,z values without any reversals, loops should match storage order. In other words, a (partial) loop:

north = region.north + (0.5 * region.nsres):

for (y=nrows-1; y >= 0; y--) {

    north -= region.nsres;

    ___get___(map, x, y, z, value)
}

is WRONG. The loop may be running from N->S but the storage is not. If I understand the intention correctly then it should be:

north = region.north + (0.5 * region.nsres):

for (y=0; y < nrows; y++) {

    north -= region.nsres;

    ___get___(map, x, y, z, value)
}

Currently we are using a locally written module that converts our data into a 3D sites file. This is then converted to a grid3 file by s.vol.idw (we need to do this because out data grid has different cell sizes across the grid). We output the grid3 file to vis5d format using r3.out.v5d. When we view the data in vis5d the N-S and T-B reversal is present, and the same is seen with the mk/showdspf although its not so obvious since there is no north indication per se.

I'm going to start modifying loops (in local code) to get the modules behaving correctly, and storing in the format mentioned above. I'll post what I find works here. Please let me know if I'm not understanding something here.

We will be gradually working through all the g3d modules to check consistency with real data.

Regards,

John Harrop

[John_Harrop]

Glynn Clements wrote:

Actually, the checks are there, but you have to explicitly choose
--with-glw and --with-motif (both are disabled by default).

The relevant make variables are:

XMINC
XMLIB
OPENGLwINC
LGLWM

AFAICT, the correct usage is:

EXTRA_CFLAGS = $(OPENGLwINC) $(OPENGLINC) $(XMINC) $(XCFLAGS)

OGLLIB = $(LGLWM) $(OPENGLULIB) $(OPENGLLIB) $(XLIBPATH) $(XMLIB) $(XTLIB) $(XLIB) $(XEXTRALIBS)

I thought I did the the same configure with both the release and exp sources. Are the checks the same for both?

[Glynn_Clements]

John Harrop wrote:

> Actually, the checks are there, but you have to explicitly choose
> --with-glw and --with-motif (both are disabled by default).
>
> The relevant make variables are:
>
> XMINC
> XMLIB
> OPENGLwINC
> LGLWM
>
> AFAICT, the correct usage is:
>
> EXTRA_CFLAGS = $(OPENGLwINC) $(OPENGLINC) $(XMINC) $(XCFLAGS)
>
> OGLLIB = $(LGLWM) $(OPENGLULIB) $(OPENGLLIB) $(XLIBPATH) $(XMLIB) $(XTLIB) $(XLIB) $(XEXTRALIBS)

I thought I did the the same configure with both the release and exp
sources. Are the checks the same for both?

Yes.

--
Glynn Clements <glynn.clements@virgin.net>