From: dmark@acsu.buffalo.edu (David Mark)
Newsgroups: comp.infosystems.gis
Subject: Re: things I (maybe) should know
Date: 3 Sep 92 18:32:16 GMT
Organization: UB

In article <GIS-L%92090311164706@UBVM.CC.BUFFALO.EDU> DHDAD@ACADVM1.UOTTAWA.CA (David_Douglas) writes:
>It was nice to get the FAQ and find the wonderful goodies available.
>I was on a long phone call so I thought I should take the opportunity to
>ftp one of the sites and get a file I have been wanting for a long time.
>I did, 3 mega bytes. After my long phone call and two coffee breaks
>I looked at it with some dismay to see a binary file, ... thus
>unreadable with any lister I knew. Next step, the "if all else fails"
>step, I got on the net again to ftp the "readme" file nearest the one I
>wanted. This is what I got.
>=======================================================================
>
>USmap.Z is US map data all the way down to the county level and was
>originally for a versatec plotter, but we don't seem to have
>a program that uses the data anymore.
>
>We think someone should be able to write a program to process it
>based on the format (someone here was once able to decipher some
>bits of it), but it's not likely to happen at UUNET.
>
>archive@uunet.uu.net
>=====================================================================
>My question:
>Do other people on GIS-L think that this is the sort of thing we should
>use the network for? I know the people making this available meant well.
>However, at the very least I think we should filter this sort of thing
>from our FAQ.  If it IS listed in a FAQ file, thus sounds like just
>EVERYONE should have, or already has it, then I would like it to be accompanied
>by a description written by someone who can also describe
>in detail how HE already USED it. The trouble is we usually end up seeing
>      ...


Sure, it would be a good idea if everything listed in the FAQ file were
up-to-date and well-documented.  Therefore, CONSTRUCTIVE criticism of the 
current FAQ is valueable, and indeed was solicited by the compilers of the FAQ.
And, by the way, I think we all owe a round of applause to Lisa Nyman and 
Virgil Sealy for doinf all the work to put this FAQ, version 1.1, together.

   (APPLAUSE!)

>And yes, I will make a habit to obtain the readme file first.

That would be a good idea.  I often try things without reading the readme, but
really have only myself to blame if I waste time and if the usage is well-
documented in the readme.

In the specific case that David talks about, the file may not be as useless
as it seems, and indeed may have been a normal, readable ASCII file when it
was put into the ftp archive.  The .Z extension almost certainly indicates
that the file was compressed using the commands documented in the following
UNIX manual page.  The systems folks here go around from time to time
and compress everything that has not been used in a while.  The files end
up with their old names, followed by a .Z.  They are uncompressed using
uncompress.  My UNIX also has zmore and zcat for showing the contents of 
compressed files directly to the screen.  VMS here has 'compress' and
'decomp' to do the same things, and claim to be almost always compatible
with the UNIX versions.

Of course, you might uncompress USmap.Z and still find that the contents do not make sense.

I guess we should add "What do those files ending in .Z mean?" to the next 
version of the FAQ...

David Mark
dmark@sun.acsu.buffalo.edu
===============================================================================
COMPRESS(1)              USER COMMANDS                COMPRESS(1)

NAME
     compress, uncompress,  zcat  -  compress  or  expand  files,
     display expanded contents

SYNOPSIS
     compress [ -cfv ] [ -b bits ] [ filename...  ]

     uncompress [ -cv ] [ filename...  ]

     zcat [ filename... ]

DESCRIPTION
     compress reduces the size of the named files using  adaptive
     Lempel-Ziv coding.  Whenever possible, each file is replaced
     by one with the extension .Z, while keeping the same  owner-
     ship  modes,   as well as access and modification times.  If
     no files are specified, the standard input is compressed  to
     the standard output.

     The amount of compression obtained depends on  the  size  of
     the input, the number of bits per code, and the distribution
     of common substrings.  Typically, text such as  source  code
     or  English  is reduced by 50-60%.  Compression is generally
     much better than that achieved by Huffman coding (as used in
     sys-unconfig(8)),   or   adaptive   Huffman   coding   (old-
     compact(1)), and takes  less  time  to  compute.   The  bits
     parameter specified during compression is encoded within the
     compressed file, along with a magic number  to  ensure  that
     neither  decompression  of  random data nor recompression of
     compressed data is subsequently allowed.

     Compressed files can be  restored  to  their  original  form
     using uncompress.

     zcat produces uncompressed output on  the  standard  output,
     but leaves the compressed .Z file intact.

OPTIONS

     [pages of options deleted].








































Solbourne Computer, Inc.9 September 1987                        3