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 <[email protected]> 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 <[email protected]> > wrote: > > > On Sat, 9 Jun 2018 at 06:25, C Hamilton <[email protected]> > 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 >
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
