Bug Report



1. Many geospatial data files, though ascii in nature, have 'line-feed' symbols at the end of each line in the data file.
Geospatial data files such as Arc/Info's interchange files (E00) when compressed by standard compression
utilities such as ZIP or GZIP become somewhat corrupted with 'line-feed' symbols when uncompressed.  I
could be wrong about the last point, I'm not entirely sure what happens after compression and uncompression;
however the problems that I've had were with compression utilities.

Line feed symbols in my editor are identified by a super-scripted letter 'L' followed by a sub-scripted letter 'F'.

I've written a small utility that can remove line-feed symbols from an ascii geospatial data file.  This utility can
not be used over the Web because my FTP utility can not handle ascii files with line-feed symbols and FTP
in binary mode doesn't seem to help either.  Using HTTP simply turns the line-feed symbols in to 'blank-lines'
thereby worsening the problem.  So the moral of the story is: make sure you don't have any of these symbols
in your ascii geospaital data files.

2. For FTP uploads, the ftp_parse utility that I've written does not preserve the cases of the directories or filenames.
Make sure your directories and filenames are in lower case letters to be on the safe side.

3. When you're testing DLGARC using some of the DLG datasets I've provided, watch whether you're using
OPTIONAL verses STANDARD DLG file read format.  The wrong selection will cause the DLGARC
command to 'bailout' so that the coverage isn't created which in turn causes a DCL error when a 'copy file'
is attemped.  The bug here is that the ARC/INFO stuff within the CGI script does not provide the user with
adaquate error feedback, ie. if an ARC/INFO command fails (perhaps due to improper input), there is no
way for the user to know what actually happend.

4. As a followup to point number 1, certain files that have originated in Windows or UNIX based systems are
not 'fully' compatable with Open VMS.  There are no exact rules in this case as far as I know at the moment.  It
could depend on the type of file, utility that it is used for and/or the method by which it was downloaded (ie.
ascii/binary, HTTP/FTP).

This is why the TIGER/Line files, which are in zipped format, can not be brought over via HTTP (with FTP you
have to run the zipped files through the BILF utility before unzipping) because our HTTP utility stores the files
in a more VMS specific format than our FTP utility.  Don't ask me why, I don't know for sure myself.  So HTTP
is off limits when using the TIGERARC utility.

The same problem exist when using the DLGARC utlity but only the other way around.  DLG files can not be
brought over with FTP however the web utility does work with HTTP. Again, it could be the file, it could
be the internet client or it could be OS.

My guess is that I need more comprehensive HTTP and FTP clients, clients that will more effectively bridge
the differences between VMS and other operating systems.


Go back to the Index Page.

Email: anp@geo.ed.ac.uk

Ignore this stuff

XX.SVF metadata text file - local http link
YY.CGM metadata text file - local http link
ZZ.MIF text file - local http link
WW.GRASS geospatial data interchange file - local ftp link
UU.ERDAS geospatial data interchange file - local ftp link