[GRASS5] g3d notes and possible bugs
Alfonso Vitti
alfonso.vitti at ing.unitn.it
Wed Jan 8 09:24:21 EST 2003
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
More information about the grass-dev
mailing list