[QGIS-Developer] Problems with QGIS 3 Hillshade

C Hamilton adenaculture at gmail.com
Sat Jun 9 11:19:45 PDT 2018


Interesting. One difference is that I am running this on an input of type
float32 with NODATA. I am on Widows 7. The data I am working with is from

http://gis3.oit.ohio.gov/geodatadownload/osip.aspx

I am using the "ESRI GRID DEM Mosaic". Here is gdalinfo.

gdalinfo per_dem
Driver: AIG/Arc/Info Binary Grid
Files: per_dem
       per_dem.aux
       per_dem.rrd
       per_dem.aux.xml
       per_dem\dblbnd.adf
       per_dem\hdr.adf
       per_dem\metadata.xml
       per_dem\prj.adf
       per_dem\sta.adf
       per_dem\w001000.adf
       per_dem\w001000x.adf
       per_dem\w001001.adf
       per_dem\w001001x.adf
       per_dem\z001001.adf
       per_dem\z001001x.adf
       per_dem\z001002.adf
       per_dem\z001002x.adf
       per_dem\z001003.adf
       per_dem\z001003x.adf
       per_dem\z001004.adf
       per_dem\z001004x.adf
       per_dem\z001005.adf
       per_dem\z001005x.adf
Size is 52000, 58000
Coordinate System is:
PROJCS["unnamed",
    GEOGCS["Unknown datum based upon the GRS 1980 ellipsoid",
        DATUM["Not_specified_based_on_GRS_1980_ellipsoid",
            SPHEROID["GRS 1980",6378137,298.257222101,
                AUTHORITY["EPSG","7019"]],
            AUTHORITY["EPSG","6019"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9122"]],
        AUTHORITY["EPSG","4019"]],
    PROJECTION["Lambert_Conformal_Conic_2SP"],
    PARAMETER["standard_parallel_1",38.73333333333333],
    PARAMETER["standard_parallel_2",40.03333333333333],
    PARAMETER["latitude_of_origin",38],
    PARAMETER["central_meridian",-82.5],
    PARAMETER["false_easting",1968500],
    PARAMETER["false_northing",0],
    UNIT["Foot_US",0.3048006096012192]]
Origin = (1974999.999999996507540,705000.000000005704351)
Pixel Size = (2.499999999999996,-2.499999999999996)
Corner Coordinates:
Upper Left  ( 1975000.000,  705000.000) ( 82d28'36.55"W, 39d56' 8.22"N)
Lower Left  ( 1975000.000,  560000.000) ( 82d28'37.03"W, 39d32'15.15"N)
Upper Right ( 2105000.000,  705000.000) ( 82d 0'47.65"W, 39d56' 4.59"N)
Lower Right ( 2105000.000,  560000.000) ( 82d 0'57.63"W, 39d32'11.54"N)
Center      ( 2040000.000,  632500.000) ( 82d14'44.72"W, 39d44'10.72"N)
Band 1 Block=512x4 Type=Float32, ColorInterp=Undefined
  Description = per_dem
  Min=618.830 Max=1199.330
  NoData Value=-3.4028234663852886e+38
  Overviews: 13000x14500, 6500x7250, 3250x3625, 1625x1813, 813x907,
407x454, 204
x227, 102x114, 51x57
  Metadata:
    LAYER_TYPE=athematic

On Sat, Jun 9, 2018 at 12:53 PM, Even Rouault <even.rouault at spatialys.com>
wrote:

> Calvin,
>
> The terrain analysis plugin in 2.18 is QGIS specific code.
>
> Your observations don't match mine. I tried on a 60,000x80,000 input TIFF
> of
> type Byte, without nodata. Ubuntu 16.04 / gcc 5.5
>
> The timings I get:
> - debug GDAL -dev & QGIS 2.18 builds:
>     * gdaldem hillshade: 11m10s
>     * terrain analysis plugin: 14m10s
>
> - optimized GDAL -dev & QGIS 2.18 builds:
>      * gdaldem hillshade: 2m35s
>      * terrain analysis plugin: 12m00s
>
> I've compared source codes between GDAL and QGIS. The overall structure is
> identical, process line by line, same type of algorithms, but the GDAL
> code
> has a few optimized paths compared to QGIS one (much less trigonometric
> computations in critical path), which explains the difference of timings
> in
> optimized builds. But not in the direction you mention.
>
> can you post the output of gdalinfo on your input DEM ?
>
> Even
>
> > I was using the Hillshade from the Terrain Analysis plugin. I don't know
> if
> > it uses GDAL for the processing or not, but it does not give a GDAL
> command
> > line. The Terrain Analysis plugin seems to be dropped for QGIS 3, but if
> > the GDAL hillshade is going to be as slow as it was, that is going to be
> a
> > serious problem for me.
> >
> > Thanks,
> >
> > Calvin
> >
> > On Sat, Jun 9, 2018 at 3:01 AM, Nyall Dawson <nyall.dawson at gmail.com>
> wrote:
> > > On Sat, 9 Jun 2018 at 06:25, C Hamilton <adenaculture at gmail.com>
> wrote:
> > > > OS: Windows 7
> > > > QGIS 3.0.3
> > > >
> > > > I have encountered several issues with the Hillshade algorithm in
> QGIS
> > > > 3.
> > > >
> > > > 1. It is much slower that the QGIS 2 hillshade perhaps as much as 10x
> > >
> > > slower. This is a problem because I process very large images. 60,000 x
> > > 80,000 pixels or greater. I eventually killed the process and went
> back to
> > > QGIS 2 to complete the job.
> > >
> > > > 2. I tried using Multidirectional shading and received an error.
> This is
> > >
> > > basically the command issued.
> > >
> > > > gdaldem hillshade input.tif output.tif -of GTiff -b 1 -z 1.0 -s 1.0
> -az
> > >
> > > 315.0 -alt 45.0 -multidirectional
> > >
> > > Can you post the command created in QGIS 2.18 for comparison?
> > >
> > > > I get the gdal error "ERROR 6: -multidirectional and -az cannot be
> used
> > >
> > > together". If multidirectional is enabled then you cannot add the -az
> > > parameter. If have tried running the same command in the command line
> and
> > > removed the -az and it worked fine.
> > >
> > > Confirmed, thanks - fixed by https://github.com/qgis/QGIS/pull/7209
> > > and unit tests added.
> > >
> > > Nyall
>
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20180609/30a5f5fc/attachment.html>


More information about the QGIS-Developer mailing list