Hi,
I would to like ask is there any plan to add following features to OpenDroneMap?
First, how I can get DSM model from OpenDroneMap?
Second, a cool feature of distance measurement is already available. how can one measure volume? Is only GPS accuracy the factor determining the accuracy of this measurement?
Third, when we say geo-referenced images, it means they have been tagged with drone position as metadata. In this case, the camera should be always looking straight down(NADIR) and not tilted, right? How about when there is a shake in the position of drone e.g. due to the wind? In this case or tilted camera, how can one incorporate IMU information into georeferencing images?
last but not least, how can one fuse LiDAR scanning point cloud with imaging point cloud?
All the best! :)
Sorry I did not find a better place to ask these questions. OpenDroneMap, unfortunately, does not have something like Google group or forum, does it?
I'll try to answer some of your questions:
First, how I can get DSM model from OpenDroneMap?
right now you can get a DEM using the --dem tag, but DSM would be a little more work. You can use the LAS point cloud found in odm_georeferencing and PDAL to generate.
Second, a cool feature of distance measurement is already available. how can one measure volume? Is only GPS accuracy the factor determining the accuracy of this measurement?
Are you referring to the distance calc in WebODM? I think volume measurement is in the pipeline. It's determined by the accuracy of the point cloud, so whatever is determining that. GPS or whatever.
Third, when we say geo-referenced images, it means the have been tagged with drone position as metadata. In this case, the camera should be always looking straight down(NADIR) and not tilted, right? How about when there is a shake in the position of drone e.g. due to the wind? In this case or tilted camera, how can one incorporate IMU information into georeferencing images?
Having the camera perfectly nadir is not necessary, because the structure-from-motion process only uses GPS as a guide to finding the nearest photos. It uses a more complex algorithm for finding matching features between images regardless of GPS position. The tilting should not be a problem.
last but not least, how can one fuse LiDAR scanning point cloud with imaging point cloud?
This is an interesting problem space- @smathermather may have some more to say.
If you have more questions, or if I didn't explain any of yours well enough, let me know.
Maybe some terminology issue here:
DEM - Digital Elevation Model - this a very generic term. can be a model of pretty much anything (from the topographic surface to values of concentration of some chemical element in the grounwater.
DSM - Digital Surface Model - a model that represents the altitude of elements over the topographic surface, including man-made objects, vegetation and the bare ground.
DTM - Digital Terrain Model - term reserved for a model of the bare topographic surface, without houses, vegetation, etc.
So @smajida asks for a DSM, which seems to be what the --dem option does. A DTM is way more complicated and is best left to be done outside ODM (IMO), by filtering and interpolations the point cloud.
I would add nDSM -- normalized digital surface model where the DSM represents height above the DTM.
--dem actually extracts the bare topographic surface via the progressive morphological filter: http://users.cis.fiu.edu/~chens/PDF/TGRS.pdf
We should probably add a --dsm option at some point to extracts ground, vegetation, buildings, etc. I'm thinking this is the output we would use to do things like volume measurements in WebODM.
I agree with @CarlosGrohmann , DTM is a complicated and important task and could be done outside ODM . For example, add break lines, noise removal, some regional constraints, fusion of other data sources, smoothing and finaly contour lines, volumes, etc.
It's an interesting method, for filtering unclassified point clouds. But on issue will always be what kind of interpolation to use, etc. I think we might keep the --dem options, but include the possibility to save/export the filtered point cloud, so it can be used in other software.
Perhaps under ODM contrib !
btw: https://grasswiki.osgeo.org/wiki/TIN_with_breaklines
@CarlosGrohmann i upload a paper to my git repo; Please, if possible, take a look in your spare time.
@dakotabenjamin I wasn't aware the --dem option existed! Is it possible that this could be added to the runtime parameters in the wiki please?
@everydayduffy
you can try some --dem switches like:
--dem --dem-sample-radius 0.25 --dem-resolution 0.2 --dem-radius 1.0
look at #578
@yjmenezes - where do you find these switches? They aren't on the Wiki and I don't know where else to look!
@everydayduffy
i guess they are not wiki documented yet.
look #459 it says: There's still some need for tweaking the default parameters.
I am following some DEM issues posts and testing.
Tip: for all up to date parameters, simply pass the --help parameter to the command line:
python run.py --help
The wiki has been updated.
@dakotabenjamin regarding fusion of Lidar and multi/hypectral spectral data which improve the quality of 3d model drastically please take a look at:
https://github.com/smajida/ros-image_cloud
http://neon-workwithdata.github.io/neon-data-institute-2016/R/neon-data-fusion-R/
\as well as:
https://github.com/yeknom/lidar-camera-fusion
That looks interesting, but those repos haven't been updated in 2 years and don't have much information about them. I'm wary of working with abandonware. If I have time I will look deeper into the code and see where we can use this. If you have ideas for this, we are always welcoming pull requests.
This issue was moved to http://community.opendronemap.org/t/asking-for-new-features-not-an-issue/378
Most helpful comment
The wiki has been updated.