Joe and list,
The problem is caused by the use of a local datum transform that requires
more than the 80-character GXF line limit to write the transform parameters.
In this case, GXF wraps and continues on the next line. The bug is that we
did not allow for this to happen for local datum transforms, although we did
account for this for the other projection parameter lines. The "[NAD83]
United States (USA) ITRF94" and "[NAD83] United States (USA) ITRF96" do
require this continuation line.
If you are experiencing this problem, the workarounds are:
1. Use <unknown> as the local datum transform.
2. Contact your local Technical Support Representative and get a hotfix
file. As a consequence you must replace this file with the original .dll
before you can upgrade to 5.0.7. Therefore you must back up the original
.dll file before adding this fix.
Tom Cuthbertson
Manager, Technical Support and Testing
Geosoft Inc.
Software and services for effective earth science decision-making.
www.geosoft.com
Geosoft Inc.
8th Floor
85 Richmond St. W.
Toronto, Ontario
Canada M5H 2C9
Tel. (416) 369-0111
Fx. (416) 369-9599
E-mail. [EMAIL PROTECTED]
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
Sent: February 5, 2001 3:09 PM
To: [EMAIL PROTECTED]
Subject: [geonet]: Problems with conversion to GXF
Has anyone observed problems with the conversion of Geosoft grids to GXF?
I am running 5.0.5 at the moment and I have observed the following
problems:
On the first row of data written to the ASCII file, the first number is not
written properly. In this particular case, the first row of data is all
dummy values and the first value in the GRID object is "32" rather than "
-1e32". Somehow or other 3 characters got lost in the shuffle. I do not
know whether this problem is consistent or data dependent.
Another problem observed is that some of the rows seem to be missing a cell
value. The net result is that anyone trying to read the file ends up with
an incorrect pointer value and in my particular case I end up trying to
read beyond the end of the data buffer.
The first problem is clearly an Oasis error and I suspect the second one is
also. I did try to read those files back into Oasis and get an unexpected
end-of-file error so I do not think it is just my program.
****************************************************************************
***
Joseph (Joe) S. Duval
Geophysicist, Eastern Mineral Resources Team
12201 Sunrise Valley Dr. MS 954
Reston, VA 20192
Phone: 703-648-6106 FAX: 703-648-6383
_______________________________________________________
More mailing list info http://www.geosoft.com/support/listserv/index.html
_______________________________________________________
More mailing list info http://www.geosoft.com/support/listserv/index.html
