nens / rastercaster Goto Github PK

The RasterCaster currently has a command line interface, which is a major obstacle for users unfamiliar with using the command line. Converting the RasterCaster into a QGIS plugin would solve this problem and is probably relatively easy to achieve due to the tool’s existing python API and QGIS’ full support for PostGIS. A QGIS plugin would to connect a graphical user interface to existing python functions.

Add validation view on rc.surface that indicated if the surface will produce a valid raster

If support for relative elevations is extended to elevation points, auxiliary lines, and ‘filler’ polygons, it will enable the user to make smooth transitions from existing elevation to the design elevations.

The polygons that are used to define elevation, may also be used to define infiltration, friction, or other 3Di raster inputs. Currently it is not possible to store multiple values per polygon.

Currently, all design heights are absolute (e.g. in m.a.s.l.), rather than relative to the base raster. In many cases, it would be much quicker if you could excavate or heighten an area with a certain value.

The current RasterCaster is build for accuracy only, not for processing speed. It would be very helpful if the user could set, for each polygon, a processing resolution that is coarser than the output resolution. This would mean balancing accuracy and processing speed according to the user’s preference.

If the RasterCaster is a QGIS plugin, it also becomes possible to allow updating the designed raster without the need to remove it from the QGIS project, greatly reducing the feedback time for the user.

Import point and polygon features, user provides mapping for source to target values. Source values can be attributes or z coordinates. Mapping can be direct or via classification/value map. Source features for point can be points or xyz vertices of features. Source features for polygons can be polygons, rings or linework.
Exceptions should be catched and reported rather then terminating the import

Allow user to choose e.g. RoadZ as definition_type and fill in the required params and aux ids to get the desired profile

The current RasterCaster’s algorithms are based on PostGIS, which has many advantages, including stability, speed, and versatility. However, it requires the user to install PostGIS, which is an obstacle for users unfamiliar with PostGIS. This can be solved by rewriting all PostGIS algorithms in python, which is a time-consuming operation.

The RasterCaster already has the technological building blocks to burn a 1D elements (e.g. channels) into a DEM, with its model-defined cross section definition. With sufficient development, it can be made possible for the user to draw a polygon and remove all 1D elements in that polygon and burn them into the DEM. This is especially useful for assessing design options when still in the sketch phase, where an integral 1D/2D model is too complex to edit.

There are some requirements to 3Di rasters that the RasterCaster does not currently enforce: valid filenames, projected coordinate system, maximum of three decimals on pixel size, output raster projection equal to global settings EPSG code, and identical data/nodata pixel locations between input rasters. Giving the user the option to enforce these constraints will guarantee that the rasters are usable as 3Di input without any problems. Another useful addition would be to constrain the output raster to active pixels in the base raster or another reference raster, to ensure that the new raster remains compatible with other existing rasters in the 3Di model.