Reimagining the use of terrain #827
Replies: 2 comments
-
In short, I want to remove the Terrain element from our study tree and instead make the associated terrain an optional property of a structure inventory. I also want to add a drop down to select a prj text file, which will be saved as property of the hydraulic dataset and serve as the target projection when reprojecting. |
Beta Was this translation helpful? Give feedback.
-
After discussing with Richard, we decided a reasonable path forward is to Set the projection in study properties. There will be an additional file browser added to every hydrualic input which is bound to the location of the study projection, which will be saved as an attribute of the study itself. The terrrain element will remain in it's place for now and is only needed optionally. |
Beta Was this translation helpful? Give feedback.
-
Terrain is used for two things in FDA 2.0 right now.
This doesn't seem intuitive through our design. Terrain should not be necessary to a study so long as the study inventory has a shapefile with populated elevations. Because we rely on it for projection, it is.
Terrain is also it's own element in our study tree. I propose it doesn't need to be. It's only use is as intermediate step in the loading of a structure inventory. The "terrain import" should be a selection box in the structure inventory importer when import ground elevations from terrain is selected.
To cover the projection target, I propose we require a projection be set explicitly when loading hydraulics using a prj file. Every RAS model has one set at project level the corresponds with the projection of the hydrualic data. we should add a drop down to the hdf hydraulic importers to set that projection and add that as a property on our hydraulic dataset object. For gridded hydraulics we can pull the projection from the tif.
Beta Was this translation helpful? Give feedback.
All reactions