Helena Mitasova - staff
helena at gis.uiuc.edu
Wed Nov 29 17:01:04 EST 2000
Bob and Markus,
I am not sure that this fix is general enough -
as I have written the problem is exactly what Bob says - that
the normals are too small and I think that they get cut-off
when they are turned to integers. This is a problem not only for
lat long but for many other cases as well (for example if your data
are between 0-1 - as in my case are the water depths) or if
somebody is using GRASS for laboratory experiments where Longdim
will be low in meters. So the fix should be in the handling of
low values for normals, rather than changing the Longdim for lat-long.
I am sending this to Bill too - is this right?
The GL version of NVIZ had that problem fixed long time ago,
because I have been looking at lots of water depth data with it -
I cannot do it now with nviz2.2
Bill, it seems that all what Bob needs at this point are the
files from your ogsf library where the normals are computed and which
have the fix. It is also possible (I hope that that is not the case),
that OPENGL handles this differently than GL amd then the fix may
be more complicated.
congrats!! It seems to be fixed. Now the colors are back in
On Wed, Nov 29, 2000 at 12:02:51PM -0400, Bob Covill wrote:
> I have found the start of a solution to the Lat/Long color problem. The
> problem I found was that the normals calculated for data in a lat long
> were extremely low in the Z direction. The factors that determine these
> are the relation bewteen the data Z range and a function called Longdim.
> Longdim is the largest X or Y dimension obtained by subtracting South
> from North, and west from east. In a UTM database this value is in
> meters and is generally quite large (> 100). In a Lat Long database the
> value is low. This is why the zexag is nviz is really small for a loaded
> surface (< 1).
I will try for different projections, unfortunately I am in a hurry
now. But I will upload this to cvs.
> I have changed how the Londim is calculated for Lat Long databases.
> Instead of subtracting degree values, I calculate the distance in
> meters. I also obtain the resolution in meters. With these values the
> zexag is a more realistic number and the normals appear to be calculated
> I have attached two files from the ogsf library which incorporate the
> changes. The first is GS2.c which implements the above changes. The
> second is a header file gsget.h. I have changed the FNORM function in
> this file and removed the GS_global_exag varibale from it. This function
> is what unpacks the normals when they are applied. I believe that the
> global_exag is already used in calculating the normals (see gs_norms.c)
> The problem with the above change to Longdim is that the data is no
> longer in the right place. Resetting the resolution changes the
> geographic coordinates. Using "Whats Here" will show how the coordinares
> have changed. Obviously the resolution has to be reset.
Mhhh. I will investigate tomorrow.
> Give the new lib routine a try a let me know how it works. Any
> suggestions or comments would help.
Many thanks so far, more comments tomorrow!
Hi developers: Please re-compile the full ogsf and NVIZ then.
Please give it a try!
If you want to unsubscribe from GRASS Development Team mailing list write to:
minordomo at geog.uni-hannover.de with
subject 'unsubscribe grass5'
More information about the grass-dev