[GRASSLIST:3887] Re: Projection and m.in.e00

[Kristopher Hein]

I opened the E00 file, converted it to an arc binary coverage (the e00 file
is compressed) and checked out the prj.adf file which is an ascii file
describing the dataset's projection.  It is not Lat Long, but rather an
Albers projection.  More specifically the parameters are:
Projection    ALBERS
Datum         NAD83
Zunits        NO
Units         METERS
Spheroid      GRS1980
Xshift        0.0000000000
Yshift        0.0000000000
Parameters
 34  0  0.000 /* 1st standard parallel
 38  0  0.000 /* 2nd standard parallel
-82  0  0.000 /* central meridian
 33  0  0.000 /* latitude of projection's origin
0.00000 /* false easting (meters)
0.00000 /* false northing (meters)

You would need to create a location with this projection and then re-project
it to Lat Long,  or what ever projection you need.

Hope this helps!

Kristopher Hein
Nanaimo, British Columbia
Canada

----- Original Message -----
From: "Ben Logan" <ben at wblogan.net>
To: "The GRASS list" <grasslist at baylor.edu>
Sent: Sunday, June 16, 2002 3:59 AM
Subject: [GRASSLIST:3884] Re: Projection and m.in.e00


> On Sat, Jun 15, 2002 at 11:20:01PM +0200, Markus Neteler wrote:
> > [...]
> > > Apparently AVECE00 and AVCE00 are the same package.  I also found the
> > [...]
> >
> > Use this utility to turn the e00 file into a binary ARC coverage and
> > then 'ogr2ogr' (from GDAL) on that to generate a SHAPE file.
>
> Okay, thanks.  If I decide to use the data with Mapserver, I'll need
> to convert to SHAPE, since it doesn't understand e00. However...
>
> > But I am not convinced that this is a good idea, since E00 is better
> > than SHAPE. It may be recommended to try harder the E00 import which
> > is known to be functional.
>
> I see your point.  Especially since I haven't yet upgraded to pre4,
> and v.in.shape is busted in pre3.  Soooo, below I've included the
> procedure I go through in order to import an e00 file.  The e00 file
> is part of the Southern Appalachian Assesment (SAA) Database, and is
> located at
> http://sunsite.utk.edu/samab/data/saa1/saa_100k/boundary.zip.  It is
> approximately 219Kb.  Perhaps one of you can see what I'm doing wrong,
> or try it yourself to see if you have the same problem.  I know that's
> a bit of trouble, but I'd really appreciate it. :)
>
> First, I crank up Grass and use an existing location (nationalatlas)
> which is in lat/lon projection.  I also use an existing mapset
> (states).  Here's the PROJ_INFO file file from the PERMANENT mapset
> looks like:
>
> name: Latitude-Longitude
> datum: nad83
> dx: 0.000000
> dy: 0.000000
> dz: 0.000000
> proj: ll
> ellps: grs80
>
> Now I'll import the e00 file (boundary.e00) into a new mapset to avoid
> the problems mentioned in the m.in.e00 manpage (the 'saa' mapset
> doesn't exist yet):
>
> GRASS:~/grass5.0/saa > m.in.e00 input=boundary.e00 mapset=saa verbose=1
logfile=out.log
>
> Here's the contents of 'out.log' after the above command:
>
> "boundary.e00" successfully opened
> ARC  2
> Arc coverage : 62 arcs (26137 points)
> CNT  2
> LAB  2
> Label table : 1 entries
> PAL  2
> PAL : 2 polygons (125 arcs referenced)
> TOL  2
> SIN  2
> LOG  2
> PRJ  2
> IFO  2
> BOUNDARY.BND XX 4 16 1
> INFO table .BND
> Creating region
> BOUNDARY.PAT XX 7 26 2
> Writing cats file "boundary.hectares_c"
> Writing cats file "boundary.acres_c"
> Writing cats file "boundary.saa"
> BOUNDARY.TIC XX 3 12 380
> getinfo returns Cover_type = 2
> EOS
> Creating dig_att(L) file "boundary"
> Updating dig_att(A) file "boundary"
> Import of boundary complete
>
> Now I'll quit Grass and restart in the new 'saa' mapset (I guess it
> isn't strictly necessary to exit Grass, but ...).
>
>  From the new mapset, I 'cd $LOCATION'.  Here's what the WIND file
> looks like:
>
> proj:       99
> zone:       0
> north:      730721.94
> south:      16980.227
> east:       353657
> west:       -420133.16
> cols:       21666124
> rows:       19984768
> e-w resol:  0.03571429
> n-s resol:  0.03571429
>
> Well, clearly this is all wrong if in fact the source e00 was in
> lat/lon projection.  So I used g.region to set the current region to
> the default value for the nationalatlas location.  That doesn't fix
> the map, though.  v.info still shows the bad numbers in the map:
>
> [...]
>     Projection: Latitude-Longitude (zone 0)
>               N:     730722    S:      16980
>             E:     353657    W:    -420133
> [...]
>
> I thought perhaps v.support would fix the problem (I'm probably
> showing my ignorance here...does v.support ever modify that type of
> info?)  I 'cd $LOCATION/dig_cats', and 'mv boundary.saa boundary'.  Then I
> run 'v.support boundary' without any errors.
>
> However, that didn't change anything--v.info still shows that the map
> boundaries are whacked out.  d.rast doesn't show anything when I try
> to display this map...which I would fully expect with those
> boundaries.
>
> I then tried running 'g.region vect=boundary', but it gives this
> message (which is also quite understandable):
>
> ERROR: Invalid region: North must be north of South
>
> And that's where I'm stuck. :(  Does anyone see what I'm doing wrong?
>
> Thanks,
> Ben
>
> --
> Ben Logan: ben at wblogan dot net
> OpenPGP Key KeyID: A1ADD1F0
>
> "I teleported home one night
> With Ron and Sid and Meg.
> Ron stole Meggie's heart away
> And I got Sidney's leg."
>
> - A poem about matter transference beams.
>