[GRASS5] g3d notes and possible bugs

John Harrop johnh at sjgeophysics.com
Wed Jan 8 15:43:35 EST 2003


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

>  
>




More information about the grass-dev mailing list