Re: [GRASS-user] .e00 to DEM
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.000,-60.000) Corner Coordinates: Upper Left ( -190574.429, 1327208.632) ( 85d36'18.54W, 34d59'5.20N) Lower Left ( -190574.429, 809888.632) ( 85d29'8.74W, 30d20'49.23N) Upper Right ( 259125.571, 1327208.632) ( 80d38'16.82W, 34d58'7.57N) Lower Right ( 259125.571, 809888.632) ( 80d48'1.00W, 30d19'54.45N) Center ( 34275.571, 1068548.632) ( 83d 7'56.55W, 32d41'16.79N) Band 1 Block=20x4 Type=Int16, ColorInterp=Undefined Min=0.000 Max=1371.000 NoData Value=-32768 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] .e00 to DEM
On Wed, 2009-07-08 at 18:19 +0200, Nikos Alexandris wrote: workspl[2]. Sorry, that is worksp1 ( 1 and not l). Nikos ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] .e00 to DEM
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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] .e00 to DEM
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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] .e00 to DEM
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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
Re: [GRASS-user] .e00 to DEM
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 ___ grass-user mailing list grass-user@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/grass-user
