[GRASS5] g3d notes and possible bugs

[Alfonso Vitti]

Hi all, Happy New Year

On Wed, 2003-01-08 at 12:01, John Harrop <johnh at sjgeophysics.com> wrote:
> 
> Message: 1
> Date: Thu, 02 Jan 2003 17:32:28 -0800
> From: John Harrop <johnh at sjgeophysics.com>
> Reply-To: johnh at sjgeophysics.com
> Organization: SJ Geophysics Ltd / Cyberquest Geoscience Ltd
> To: grass-dev <grass5 at 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