The direction of a Slope is known as its Aspect. It's usually defined as the direction the slope "faces", to me that's a little ambiguous and it's more intuitive to think of it as the "downhill" direction. Slope (the percentage you have already calculated) and Aspect will usually be two separate rasters. Depending on the tool you used to generate the Slope ...
If you create a slope layer from Raster > Terrain Analysis > Slope, the output layer will have degrees as units of measurement.
Instead, using the Slope GDAL tool from the Processing Toolbox will allow expressing the slope as a percent, instead of degrees (they are the default unit):
There is also the Slope, aspect, curvature SAGA tool from the Processing ...
The problem is because the DTM has a high-resolution pixel size when data (in my opinion) doesn't have the same resolution is some areas.
For example, direct hillshade raster:
Check pixel values (using Raster values to points over the hillshade ugly raster):
That's why look so ugly hillshade or slope outputs. You need to aggregate to obtain a better look ...
In the QGIS Processing Toolbox, there are GRASS tools v.split.length and v.drape (using QGIS 2.18.16).
0.) make sure your DEM and road data are projected onto the same CRS.
Then, following your summary workflow:
1.) split line (forest road) into equal lengths segments
v.split.length will give you a new layer Split by length by default.
Slope analysis is performed on a DEM (raster layer with elevation values). This is one way to do it. If your contours have an elevation value, you can use the interpolation option (raster/interpolation) to produce a DEM. For instance, here are my contours as a shapefile
The attribute table do have a value for altitudes in the "elevacion" field.
Now you can ...
Contours do not cross each other, so I cannot explain it using your example. Instead, let me illustrate what this ACS does by a picture below.
Looking at the pictures  and , you will find steep slope is represented by dense contours , hence the total length of contours gets longer than in gentle slope area .
What this ACS is good at is seen in ...
Aster DEMs are in EPSG 4326 (lat lon WGS84). According to the GDAL DEM documentation:
For LatLong projections near the equator, where units of latitude and units of
longitude are similar, elevation (z) units can be converted to be compatible
by using scale = 370400 (if elevation is in feet) or scale = 111120 (if
elevation is in meters). For ...
You mention 3D Analyst so I am assuming you have ArcGIS.
Use the tool ArcToolbox-3D Analyst Tools-Raster Surface-Slope to create a slope surface from your LiDAR data.
Use the tool ArcToolbox-3D Analyst Tools-Raster Reclass-Reclassify and give all the values > 5% slope NoData, and all the areas <=5% slope a value of 1. All the pixels with a value of ...
It looks like you are not using a digital elevation model (DEM) data. It is just an image (scanned image) from layout or something and not a real elevation data. You need to use elevation data such as SRTM data or any other data that stores elevation. Working with scanned figures will not produce any meaningful results.
The slope of a surface is determined by the angle made by its normal (perpendicular) vector to the "straight up" direction. The relevant vectors are the 3D gradient of the surface (thought of as the zero set of a differentiable function) and the "straight up" vector (0,0,1). Angles are determined by dot products, leading to straightforward formulas....
Subtract the trend surface from the DEM.
Linear trend (1st order polynomial)
2nd order polynomial trend
Per @radouxju's comment - the trend line can be shifted down to avoid negative values by adding the minimum value.
In the Raster Calculator:
"DEM" - Trend("DEM") + N
Where: N = Minimum raster value in the DEM
I think I see the problem.
I could reproduce this, both using your script, and SAGA itself. The output from SAGA matches the output from your script. So it's not RSAGA.
But look at the slope output from SAGA... vast areas are near-vertical, with slopes around 1.57 radians (nearly 90 degrees) with some flat areas. You can confirm this looking at the ...
As @Hornbydd pointed it is network searching problem. I suggest the following workflow:
find source points of the streams
sort them in descending order by flow length
In the picture below 139 green points are sources labelled by their sequential order and elevation, e.g. remotest point (1/435).
There are 2 possible paths from here:
Trace and dissolve ...
Use the gdaldem tool http://www.gdal.org/gdaldem.html as
gdaldem slope input.dem output_in_percents.tif -p -of GTiff
From the manual page: "-p : if specified, the slope will be expressed as percent slope. Otherwise, it is expressed as degrees "
QGIS generates a similar gdaldem command and degrees/percents is selected here:
The following is a rough outline of what you might do. I won't include a great deal of detail, you can research further using these terms and/or ask new more specific questions.
Note: you will need to careful of coordinate systems. Firstly that they are the same for your datasets, and second that they use metric (metres) horizontal units (not actually ...
Each of the outputs that you described (slope, aspect, and curvature) are terrain attributes that are naturally described as rational numbers. As such, you would expect that the outputs of these tools would be floating point rasters even if the input DEM uses integer level data to characterize elevations. And no, it does not corrupt your analysis. The only ...
You can generate the slope in several ways:
Raster -> Analysis -> DEM -> Slope. Or via slope functions in the Processing framework (r.slope.aspect). Run it on your DEM. Do the same for the aspect.
Create two new fields in your point layer (to hold the data).
Use v.sample from Processing to assign values from the new rasters to your point layer. Or do it the ...
If you want to use a field in attribute table, you should select the field directly in the Data defined override which has the angle value. The field should be of double/integer type not string field type. In the following figure I used at first Single Symbol and select Data defined override beside the rotation field, as you can see below:
Then, I changed ...
This is a modification of Kazuhito's answer using native QGIS algorithms using QGIS 3.12.
In the QGIS Processing Toolbox, there are the tools Split lines by maximum length and Drape (set Z value from raster).
0.) make sure your DEM and road data are projected onto the same CRS.(This is no longer strictly necessary in QGIS 3.x using native ...
Should be possible to do if you feel like hacking your qgis install.
look for this file in your qgis install: https://github.com/qgis/QGIS/blob/master/python/plugins/processing/algs/saga/description/Slope%2CAspect%2CCurvature.txt
you need to change the lines corresponding to all the optional outputs. From http://www.saga-gis.org/saga_tool_doc/2.2.3/...
If you do not care about what happens between your two ends (not that this is dangerous for long roads in hilly regions), here are the steps :
1) feature vertices to points (ask for START and for END)
2) extract values to points (for both sets of points, don't forget to check the "interpolate" box)
3) join by attributes (based on ID) the starts and the ...
Interesting. I just did the same thing, with the same results. It turns out that QGIS assumes that the vertical units are the same as the CRS units.
My test image was unprojected Lat/Lon and I'm assuming yours is too? I reprojected the image to UTM (so units would be meters) and the slope calculation worked just fine.
To try this yourself, right-click on ...
I think this post in the SAGA GIS forum might prove useful in answering your question about how slope is calculated:
Also, based on my understanding of TWI (as a PhD hydrology student involved in hydrologic modeling), the D-Inf (Tarboton), MFD-md (Qin), DEMON (Costa-Cabral), and MFD (...
Join the points to the lines, using a spatial or table join, to give the elevation (Z) at each end of the line. This allows you to calculate the elevation change (Z1 - Z2). Use your GIS to calculate the 2D length of the line (Shape.length).
This allows you to use SOHCAHTOA to calculate the slope angle.
tan(slope) = (opposite / adjacent)
slope = atan(...
Doing this kind of processing is pretty straight-forward, but there are some tricks along the way that will determine how accurate your analysis will be. Your data will be generated from a slope raster of the area, and you usually have to build it yourself. The easiest way is to use a DEM raster to calculate the slope, so you should start with that.
Step 1: ...
If the Aspect raster converted to polygon or you have a shapefile with "Aspect" field name in the attribute table and you need to put the text definition, then you are almost there, but you need to put "Aspect" before >= not after:
WHEN "Aspect" < 22.5 THEN 'N'
WHEN ("Aspect" >= 22.5 AND "Aspect" < 67.5) THEN 'NE'
WHEN ("Aspect" >= ...
Before creating your slope layer (Slope tool is the right choice) you can use the Resample tool to change the cellsize of your input raster, without changing the rasters extent.
It is however important that you change Resampling Technique to Bilinear or Cubic which is the right choice for continuus data.
You could run "Raster pixels to polygons", to convert your raster to a vector layer:
Make sure your Buildings have a unique id, then run "Intersection" with your Buildings:
So your attribute table contains the slope value in degrees and the building id. Now add a new field, counting the cells each building contains count("...
There is a python plugin for QGIS to calculate Tobler's Hiking function. It's called Walking times and you can install it using the qgis oficial repository.
The plugin page explains how it works:
And, since we are talking about open source, you can see and download all the code here: