[GRASS-user] .e00 to DEM

GRASS GRASS user
,
1

The data I would like to import in GRASS is here:
http://csat.er.usgs.gov/statewide/layers/dem250.html

I have tried r.in.gdal with no sucess. I will provide anything that
is helpfull. This is my second post, so I don't know what would be
helpful.
thanks for the help,

--
Stephen Sefick

Let's not spend our time and resources thinking about things that are
so little or so large that all they really do for us is puff us up and
make us feel like gods. We are mammals, and have not exhausted the
annoying little problems of being mammals.

                -K. Mullis

2

On Wed, 2009-07-08 at 10:57 -0500, stephen sefick wrote:

The data I would like to import in GRASS is here:
http://csat.er.usgs.gov/statewide/layers/dem250.html

I have tried r.in.gdal with no sucess. I will provide anything that
is helpfull. This is my second post, so I don't know what would be
helpful.
thanks for the help,

Hi.

I've downloaded the GRID [1] file. "gdalinfo" works (with some reported
errors) on the "dem250/" directory which is stored within "workspl"[2].

So I created a location based on the data itself (using the dem250
directory as a source) and imported in grass with r.in.gdal (again using
the dem250 directory as input).

---
# enter in _some_ location and create another-one based on the data
g.proj -c location=albers_us georef=/geo/geodata/world/us/worksp1/dem250

# exit from current location, enter in newly created one
grass64 /geo/grassdb/global/albers_us/PERMANENT/

# import data
r.in.gdal in=/geo/geodata/world/us/workspl/dem250 out=dem250
---

There is something strange with the values though (they expand from min
= -32687 max = 32645). Don't have the time to dig further, maybe there
are details in the meta-data about it (!?).

Good Luck, Nikos
---

[1] http://csat.er.usgs.gov/download/statewide/dem250grid.zip

[2] gdalinfo dem250/
ERROR 3: Attempt to read past EOF in dem250//../info/arc.dir.
ERROR 4: Failed to open table .VAT
Driver: AIG/Arc/Info Binary Grid
Files: dem250/
       dem250/dblbnd.adf
       dem250/hdr.adf
       dem250/log
       dem250/prj.adf
       dem250/sta.adf
       dem250/vat.adf
       dem250/w001001.adf
       dem250/w001001x.adf
Size is 7495, 8622
Coordinate System is:
PROJCS["unnamed",
    GEOGCS["NAD83",
        DATUM["North_American_Datum_1983",
            SPHEROID["GRS 1980",6378137,298.257222101,
                AUTHORITY["EPSG","7019"]],
            TOWGS84[0,0,0,0,0,0,0],
            AUTHORITY["EPSG","6269"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9108"]],
        AUTHORITY["EPSG","4269"]],
    PROJECTION["Albers_Conic_Equal_Area"],
    PARAMETER["standard_parallel_1",29.5],
    PARAMETER["standard_parallel_2",45.5],
    PARAMETER["latitude_of_center",23],
    PARAMETER["longitude_of_center",-83.5],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["METERS",1]]
Origin = (-190574.428637420991436,1327208.631963560357690)
Pixel Size = (60.000000000000000,-60.000000000000000)
Corner Coordinates:
Upper Left ( -190574.429, 1327208.632) ( 85d36'18.54"W, 34d59'5.20"N)
Lower Left ( -190574.429, 809888.632) ( 85d29'8.74"W, 30d20'49.23"N)
Upper Right ( 259125.571, 1327208.632) ( 80d38'16.82"W, 34d58'7.57"N)
Lower Right ( 259125.571, 809888.632) ( 80d48'1.00"W, 30d19'54.45"N)
Center ( 34275.571, 1068548.632) ( 83d 7'56.55"W, 32d41'16.79"N)
Band 1 Block=20x4 Type=Int16, ColorInterp=Undefined
  Min=0.000 Max=1371.000
  NoData Value=-32768

3

On Wed, 2009-07-08 at 18:19 +0200, Nikos Alexandris wrote:

"workspl"[2].

Sorry, that is worksp1 ( "1" and not "l").
Nikos

4

On Wednesday 08 July 2009, Nikos Alexandris wrote:

There is something strange with the values though (they expand from min
= -32687 max = 32645). Don't have the time to dig further, maybe there
are details in the meta-data about it (!?).

This looks like an overflow problem. Could it be that this file contains
unsigned 16 / 32 bit integers, but is being read in as signed 16 bit
integers?

This used to happen when reading in Arc ASCII grids that contained very large
numbers (> 32768) somewhere other than in the first couple of lines. I am
pretty sure this bug has been fixed-- but I am not sure how GDAL is
interpreting this specific file. It would be useful to use gdal_translate to
copy the file, forcing the bit-size of the output to something else.

Here was the original GRASS ticket: http://trac.osgeo.org/grass/ticket/166
and the subsequent GDAL ticket: http://trac.osgeo.org/gdal/ticket/2369

There are some tips in the GDAL ticket on forcing a file to be read as a 32bit
integers (etc.). Quoth Frank W:

Note that with gdal_translate you can convert pixel types on the fly, so if
you know the data range is suitable for Int16, you could
do "gdal_translate -ot Int16 in.grd out.tif" for instance.

Cheers,
Dylan

--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341

5

On Wed, 2009-07-08 at 09:51 -0700, Dylan Beaudette wrote:

On Wednesday 08 July 2009, Nikos Alexandris wrote:
> There is something strange with the values though (they expand from min
> = -32687 max = 32645). Don't have the time to dig further, maybe there
> are details in the meta-data about it (!?).

This looks like an overflow problem. Could it be that this file contains
unsigned 16 / 32 bit integers, but is being read in as signed 16 bit
integers?

Probably you are right Dylan. In the meta-data it is written:

<< Level 2 DEM: Level 2 DEMs may contain void areas due to interruptions
to contours in the source graphic or DLG. Void area elevation grid posts
are assigned the value of -32,767. >>

* This means that original data are for sure Signed (probably
Int16-bit... ?).

* gdal reads the data correctly (look previous post of mine) as:
  Band 1 Block=20x4 Type=Int16, ColorInterp=Undefined
  Min=0.000 Max=1371.000
  NoData Value=-32768

* grass reports the range of the imported data as:
r.info dem250 -tr
min=-32687
max=32645
datatype=CELL

* The data show up correctly in GRASS:

g.region rast=dem250 && r.colors dem250 color=terrain && d.mon x0 &&
d.rast dem250

If we accept min=-32687 that was assigned to be nodata, what is this
max=32645?

Nikos

6

On Wednesday 08 July 2009, Nikos Alexandris wrote:

On Wed, 2009-07-08 at 09:51 -0700, Dylan Beaudette wrote:
> On Wednesday 08 July 2009, Nikos Alexandris wrote:
> > There is something strange with the values though (they expand from min
> > = -32687 max = 32645). Don't have the time to dig further, maybe there
> > are details in the meta-data about it (!?).
>
> This looks like an overflow problem. Could it be that this file contains
> unsigned 16 / 32 bit integers, but is being read in as signed 16 bit
> integers?

Probably you are right Dylan. In the meta-data it is written:

<< Level 2 DEM: Level 2 DEMs may contain void areas due to interruptions
to contours in the source graphic or DLG. Void area elevation grid posts
are assigned the value of -32,767. >>

* This means that original data are for sure Signed (probably
Int16-bit... ?).

* gdal reads the data correctly (look previous post of mine) as:
  Band 1 Block=20x4 Type=Int16, ColorInterp=Undefined
  Min=0.000 Max=1371.000
  NoData Value=-32768

* grass reports the range of the imported data as:
r.info dem250 -tr
min=-32687
max=32645
datatype=CELL

* The data show up correctly in GRASS:

g.region rast=dem250 && r.colors dem250 color=terrain && d.mon x0 &&
d.rast dem250

If we accept min=-32687 that was assigned to be nodata, what is this
max=32645?

Nikos

Hi Nikos,

Looks like a 16bit signed integer file. I have found that in the past using
gdal_translate and manually setting the data type and nodata value results in
the generation of a new file that GRASS can read in without further work.
Also, have you tried manually setting NULL cells with

r.null setnull=32768

Sometimes GRASS isn't notified of the nodata upon importing...

Dylan

--
Dylan Beaudette
Soil Resource Laboratory
http://casoilresource.lawr.ucdavis.edu/
University of California at Davis
530.754.7341

7

Nikos:

> * gdal reports:
> Band 1 Block=20x4 Type=Int16, ColorInterp=Undefined
> Min=0.000 Max=1371.000
> NoData Value=-32768

> * grass reports:
> r.info dem250 -tr
> min=-32687
> max=32645
> datatype=CELL

Did you notice that gdal's "NoData Value=-32768" != grass' "min=32645" !
= grass' "max=32645". It's not a typo of mine. Where are these values
(that grass reports) coming from?

Dylan:

Looks like a 16bit signed integer file. I have found that in the past using
gdal_translate and manually setting the data type and nodata value results in
the generation of a new file that GRASS can read in without further work.

Will try.

Also, have you tried manually setting NULL cells with
r.null setnull=32768

Does not help unfortunately.
Nikos