On several raster DEM files downloaded from the Oregon LiDAR Consortium
r.gdal reports it cannot read hdr.adf. The OLC data maintainer tells me he
has no issues using ArcGis. Is there a way for me (or someone more
knowledgable) to figure out why r.gdal has reading issue and fixing them?
Regards,
Rich
On Mon, Sep 23, 2019 at 8:07 PM Rich Shepard <rshepard@appl-ecosys.com> wrote:
On several raster DEM files downloaded from the Oregon LiDAR Consortium
r.gdal reports it cannot read hdr.adf. The OLC data maintainer tells me he
has no issues using ArcGis. Is there a way for me (or someone more
knowledgable) to figure out why r.gdal has reading issue and fixing them?
Well, without error message nor link to the data it is hard to say.
In addition, it is usually worthwhile to check a dataset with gdalinfo.
Markus
On Mon, 23 Sep 2019, Markus Neteler wrote:
Well, without error message nor link to the data it is hard to say.
Markus,
True. I wondered about general approaches.
In addition, it is usually worthwhile to check a dataset with gdalinfo.
Hmm-m-m. I didn't know I could do this. I'll read the gdalinfo man page
again and see what I can learn.
Will download the .zip files again and try again to import them correctly.
Thanks,
Rich
On Mon, 23 Sep 2019, Markus Neteler wrote:
Well, without error message nor link to the data it is hard to say.
In addition, it is usually worthwhile to check a dataset with gdalinfo.
Markus,
I'm dealing with two separate issues: r.in.gdal/r.import unable to read
hdr.adf and maps that are supposed to fit tightly to the border of a topo
quad rectangle don't. I'll deal with the latter issue first.
I separated the orginal bare-earth dataset for one portion of the topo quad
and uploaded it to fileconvory.com
<http://www.fileconvoy.com/dfl.php?id=g180d8982ad7f3f731000197000c9cb9624a57ea50a>\.
Even xz compressed it's 550MB large. It will be available at that URL for 5
days.
The output of gdalinfo -proj4 on the w* file is the same as that in the
prj.adf file.
My workflow started with creating a new location using the prj.adf file to
set the projection. Then I applied r.in.gdal to the hdr.adf. Displaying the
imported file shows it is slightly rotated clockwise (see attached file
h5clatsop.png). The other two maps in this topo quad import and display
correctly (the three can be seen in the attached file, 45123a5_clatsop.png.
I'm at a loss to understand why the imported map is not square with the topo
boundary. The gdalinfo -proj4 results (attached) show different coordinates
for the northwest and southwest but the OLC data coordinator tells me the
map displays correctly for him and one of his colleagues.
Regards,
Rich
gdalinfo-results.txt (1.8 KB)
On Tue, Sep 24, 2019 at 12:34 AM Rich Shepard <rshepard@appl-ecosys.com> wrote:
On Mon, 23 Sep 2019, Markus Neteler wrote:
Well, without error message nor link to the data it is hard to say.
In addition, it is usually worthwhile to check a dataset with gdalinfo.Markus,
I’m dealing with two separate issues: r.in.gdal/r.import unable to read
hdr.adf and maps that are supposed to fit tightly to the border of a topo
quad rectangle don’t. I’ll deal with the latter issue first.I separated the orginal bare-earth dataset for one portion of the topo quad
and uploaded it to fileconvory.com
<http://www.fileconvoy.com/dfl.php?id=g180d8982ad7f3f731000197000c9cb9624a57ea50a>.
Even xz compressed it’s 550MB large. It will be available at that URL for 5
days.
I used r.in.gdal in=be_45123h5 out=be_45123h5, i.e. the coverage directory as input (GDAL recognizes this as an AIG/Arc/Info Binary Grid).
The output appears slightly tilted (rotated clockwise), but this is apparently correct: the data match other elevation data. The topo quad rectangle is probably a guide whereabouts the DEM should be located. If in doubt you need to supply the corresponding topo rectangle for testing, without any modification of course.
The DEM as it is imported into GRASS seems correct. Any rotation will introduce errors.
Markus M
The output of gdalinfo -proj4 on the w* file is the same as that in the
prj.adf file.My workflow started with creating a new location using the prj.adf file to
set the projection. Then I applied r.in.gdal to the hdr.adf. Displaying the
imported file shows it is slightly rotated clockwise (see attached file
h5clatsop.png). The other two maps in this topo quad import and display
correctly (the three can be seen in the attached file, 45123a5_clatsop.png.I’m at a loss to understand why the imported map is not square with the topo
boundary. The gdalinfo -proj4 results (attached) show different coordinates
for the northwest and southwest but the OLC data coordinator tells me the
map displays correctly for him and one of his colleagues.Regards,
Rich_______________________________________________
grass-user mailing list
grass-user@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-user
On Tue, 24 Sep 2019, Markus Metz wrote:
I used r.in.gdal in=be_45123h5 out=be_45123h5, i.e. the coverage directory
as input (GDAL recognizes this as an AIG/Arc/Info Binary Grid).
Markus M,
Interesting. I thought the .adf format was EVIN or Ehdr. Regardless,
r.in.gdal had no problems importing it here, except for the rotation.
The output appears slightly tilted (rotated clockwise), but this is
apparently correct: the data match other elevation data. The topo quad
rectangle is probably a guide whereabouts the DEM should be located. If in
doubt you need to supply the corresponding topo rectangle for testing,
without any modification of course.The DEM as it is imported into GRASS seems correct. Any rotation will
introduce errors.
I just re-imported and re-projected the map and it does fit much better than
the first couple of times I did this. Very strange. Adding that one portion
to the basin map (attached) the minor breaks are not visible.
Thanks for prompting me to try again. Now on to the other missing pieces.
Best regards,
Rich
