Jannik-Schilling / generate_swmm_inp

a QGIS plugin for the import and export of SWMM input files (conversion of geodata, e.g. shapefiles or geopackage into SWMM models and vice versa)
GNU General Public License v2.0
35 stars 11 forks source link

Fetch transect station/elevation info from DEM #67

Open schoeller opened 1 year ago

schoeller commented 1 year ago

Dear all,

thanks for making your work opensource. From browsing the code and importing Test_5_2.inp I figure that transect information is read from the joint file test52_gisswmm_transects.xlsx, table XSections. I kindly request a mechanism to generate station / elevation info to that xlsx-file from a provided raster file in conjuction with a polyline.

Best regards

Sebastian

Jannik-Schilling commented 1 year ago

Good Idea! I already wrote/used a similar function with DEMs in order to make line geometries of watercourses more accurate. Such a mechanism could directly be applied to a "condiut layer" in QGIS if it is an "Action".

There are some decisions have to be made, either by default or by the user (each time the action is executed)

schoeller commented 1 year ago

@Jannik-Schilling: Thanks for your reply. I am commenting as below with my humble understanding. It could well be that I have mis-understood some points.

Good Idea! I already wrote/used a similar function with DEMs in order to make line geometries of watercourses more accurate. Such a mechanism could directly be applied to a "condiut layer" in QGIS if it is an "Action".

In my understanding: if modifying a polyline object (or the attached node from a topological dataset) the action is executed and thus geometry may be read/written through an underlying logic.

There are some decisions have to be made, either by default or by the user (each time the action is executed)

* at which location of a (poly)line should the transect be created? You need to find a transect which is representative for the whole line. This could be at the first vertex, at the last vertex or somewhere in the middle of the line. In my opinion it would be better leave that decision to the user

To my understand the transect is representative as for the entire conduit, since it is defined in absolute levels. The geometric tables are uniformly generated. The slope of the irregular section is defined by the level of its end nodes, but the actual geometric tables are uniform throughout the conduit. If a modeller wants to improve calculation results, one thus has to split the strem into as many as possible/reasonable conduits. The question of where to digitize from DEM comes thus second to how many I may digitize. To reduce the workload for the modeler the polyline should be reduced to segments, thus each polyline vertex becoming a node and each polyline segment becoming a conduit. The transect could then be digitized at each midpoint of segment. For the xy-sections goings across this becomes the cross of the modeler, which is to place the cross-section lines in a non self-crossing manner. As the cross-section lines become longer, the need grows for have customizeable lines for each cross-section. Somewhere in between a compromise has to be made.

* should the resulting transect data be saved to a new file each time or can it be written to an existing file? What if there are already transects defined (at least for some lines in the conduits layer)?

The conversion from GIS/TABLES->INP is launched manually. It should be ensured that each time this is done the corresponding underlying definition matches the expected outcome, which is GIS/TABLES->INP. Thus GIS and TABLES must be synchroneous at all times.

* length of the transects

I my opinion it should be customizeable.