I am working on a project that requires some refined handling of elevation models over waterways and I am refining an approach that looks quite promising. With defaults, we see a terrain model that looks something like this (presented in QGIS, so trimmed with a mask, etc.):
It’s a bit messy to say the least, especially along the shorline. With some refinement of approach, and the addition of a minimum elevation, we can get something like this (with 1m contours added so you can see how smooth it is):
That looks really good! I vote for including in ODM with a separate configuration option (vs separate processing utility). If no other test data appears, I’ll check my archives when I’m back in the office at the end of the week.
A vote for integration, and I look forward to the data! I tested a second dataset, and it worked well, but is not without it’s challenges, so other examples still quite welcome, as I’m sure we’ll find some edge cases (DTM, with hillshade and contours (1m) after processing only):
We can see this one doesn’t isolate the water as well, but I’ve got another project in the pipeline for that. We can’t expect a single parameter model to do all the heavy lifting, I guess.
Alright two for standalone, one for integrated. I lean toward integrated myself, as I think this is a common problem space, and improves the veracity and verisimilitude of the outputs considerably when used appropriately. I’m unlikely to build a plugin, as that level of effort would compete with other tasks that need done, but happy to release as a utility if that’s where we go with it.
Also, thinking a bit deeper about the process, this is more a change in the processing pipeline – it modifies products and processing pipeline, fits in best early in the pipeline. For this reason, it either needs to be an independent utility used to modify the point cloud and then feed back into the pipeline to write a new set of DEMs, mesh, and orthophoto, or it needs to be a flag. I’m currently testing it after filtering on the georeferenced LAZ files, but it likely needs to happen on the OpenMVS output prior to georeferencing.
(Side note: once I finish working on the water removal (similar to sky and background removal) tool, I could see some marriage of that with this approach, but that will take some thought.)
Anyway, it might be premature to decide which it should be until we have more outputs and test datasets though, and I publish a bit more on how the approach works and what I think it’s use cases are.
In the meantime, here’s another test dataset, this one with proper flat water unlike the river examples:
And here’s a couple of intrepid explorers verifying the flatness of the water as some dolphins zoom through in the background:
Moved the filtering up in the pipeline a bit to filter before the mesh. I’ve got a bit more refining to do on that, but the initial results are promising. GIF is a sequence of 3 images: untextured default mesh, textured default mesh, improved mesh with flat water:
Is there any hope of reconstructing this type of smooth water surface from photos of a shoreline experiencing wave-action? I have a test dataset if you ever try.
I work for a Port Authority and so have large areas of water within our area. As the water is within the Harbour area it is by definition relatively calm. I could supply you with some data if you message me and let me know what you need.
Oh and my vote would 100% be for something integrated with an option to toggle on/off. To me as a lightning user it makes zero sense for this to be something separate.
I definitely have some super useful datasets. I’ll be traveling the next couple weeks, but keep them coming! The variety so far is breathtaking and informative.
Bonus points for anyone who has images of water collected with DJI Mavic 3 multispectral variants… . Cheers!
@Smathermather
I have a few datasets from a variety of DJI aircraft (not M3 Multi though), all with fresh water shorelines that I am willing to share.
How would you like to receive them?
