<div dir="ltr"><br><br>On Tue, Sep 24, 2019 at 12:34 AM Rich Shepard <<a href="mailto:rshepard@appl-ecosys.com">rshepard@appl-ecosys.com</a>> wrote:<br>><br>> On Mon, 23 Sep 2019, Markus Neteler wrote:<br>><br>> > Well, without error message nor link to the data it is hard to say.<br>> > In addition, it is usually worthwhile to check a dataset with gdalinfo.<br>><br>> Markus,<br>><br>> I'm dealing with two separate issues: r.in.gdal/r.import unable to read<br>> hdr.adf and maps that are supposed to fit tightly to the border of a topo<br>> quad rectangle don't. I'll deal with the latter issue first.<br>><br>> I separated the orginal bare-earth dataset for one portion of the topo quad<br>> and uploaded it to <a href="http://fileconvory.com">fileconvory.com</a><br>> <<a href="http://www.fileconvoy.com/dfl.php?id=g180d8982ad7f3f731000197000c9cb9624a57ea50a">http://www.fileconvoy.com/dfl.php?id=g180d8982ad7f3f731000197000c9cb9624a57ea50a</a>>.<br>> Even xz compressed it's 550MB large. It will be available at that URL for 5<br>> days.<br><div><br></div><div></div><div>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).</div><div><br></div><div>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.<br></div><div><br></div><div>The DEM as it is imported into GRASS seems correct. Any rotation will introduce errors.</div><div><br></div><div>Markus M<br></div><div><br></div><div>></div>> The output of gdalinfo -proj4 on the w* file is the same as that in the<br>> prj.adf file.<br>><br>> My workflow started with creating a new location using the prj.adf file to<br>> set the projection. Then I applied r.in.gdal to the hdr.adf. Displaying the<br>> imported file shows it is slightly rotated clockwise (see attached file<br>> h5clatsop.png). The other two maps in this topo quad import and display<br>> correctly (the three can be seen in the attached file, 45123a5_clatsop.png.<br>><br>> I'm at a loss to understand why the imported map is not square with the topo<br>> boundary. The gdalinfo -proj4 results (attached) show different coordinates<br>> for the northwest and southwest but the OLC data coordinator tells me the<br>> map displays correctly for him and one of his colleagues.<br>><br>> Regards,<br>><br>> Rich_______________________________________________<br>> grass-user mailing list<br>> <a href="mailto:grass-user@lists.osgeo.org">grass-user@lists.osgeo.org</a><br>> <a href="https://lists.osgeo.org/mailman/listinfo/grass-user">https://lists.osgeo.org/mailman/listinfo/grass-user</a></div>