Hi Everyone,
So glad I gave WebODM a chance. I am very impressed with this free and open source product. Great job to the community and all those involved.
I have been in the GIS technology arena for over 20 years and in CAD nearly 25 years. One of my main responsibilities is preparing 3D data for geologists and engineers. 3D data can include DEMs, DSMs, or LiDAR, but the final result is always contours at various intervals. In addition, knowledge of different coordinate systems and units of measure goes with the territory. I have been working with drone data in particular for around 6 years.
I have been using WebODM for around a month and have noticed some anomalies in the LAS, surface and terrain models, but the Ortho-rectified mosaics work great. Maybe, most of the users use it for visualization, but my goal is to create other products from all three. I am convinced that the elevation values are not maintained during export. I have tried all the formats and compared it to a cloud based system similar to Drone Deploy or Pix4D. It’s not a units, meters to feet, issue. I am willing to work with the engineers and programmers to get this right. The ability to create additional products would elevate WebODM from good to great! Hopefully, I just missed a parameter.
Details: HP Z820 workstation, Manjaro Linux, 6 GB video, 128 GB memory, 14 TB storage
Regards,
Gerry
1 Like
Hey Gerry 
it looks like you exported your elevation model as RGB (the default, so you’re getting a pretty picture), if you want the elevation values make sure to export the “Raw” model when you save the DSM.
Cheers!
1 Like
Thanks for your reply.
Closer, but still didn’t work. Even the graphic is off. My average elevation is 167 feet or 51 meters. The range displays 13 to 35. I assume in meters since the data is in geographic coordinates. Compare the two below. Version six is in feet, correct, and matches Drone Deploy. Version 3 is WebODM and I don’t know what the range means.
Regards,
Gerry
1 Like
Are you able to share your processing parameters with us?
Saijin,
From what application? Just WebODM, or QGIS and ArcGIS Pro?
1 Like
Let’s just start from WebODM and see how you processed things. If somethings really amiss, we have to help you starting from there, ideally.
Do you think you’d be able to share your all.zip export from WebODM somewhere for us to look at as well?
The share all zips are around 485 meg. Where can I upload? Is there an easy way to pull parameters. I ran 3 tasks with different settings to try to figure this thing out. I guess I can make movie files.
Thanks,
Gerry
1 Like
Maybe, another issue. It doesn’t look like the settings kept. I know I used ultra for feature quality and pc-quality.
1 Like
Found the text output.
console.pdf (1.2 MB)
console (1).pdf (1.2 MB)
console (2).pdf (1.2 MB)
1 Like
I’ll try again with my Evo II Pro when the weather gets better. I used DJI data for this one so I can compare to a project that I can reproduce.
1 Like
A change of drone, and thus how the drone is recording elevation could make a big difference. Some DJI’s record height above takeoff instead of GPS elevation. It is more accurate in a relative sense, but meaningless in an absolute sense. Now it may be that we should be reading a different value from the exif data, so sharing example data helps. Take a look at DroneDB for sharing your raw images.
1 Like
Thanks for your reply. Here is a subset of consecutive images. Maybe, you can reproduce from this.
1 Like
Please send them by a different means. This means I have to download each individually, but also strips them of any meaningful image tags:
DroneDB is a good way to share, as would be Google Drive or similar.
Thanks!
2 Likes
I should add to this: please share a cluster of images (or all of them) rather than a strip of images. Something that allow for reconstruction is much more useful for troubleshooting than a strip of images that cannot be used in WebODM.
2 Likes
My p4p records altitude according ASL (gpsaltitude) and above take off (relativealtitude) all of which is recorded in the exif metadata. However I have seen my p4p altitude data be more than 40 meters off from the true altitude. If GCP’s are used with a geo_z measurement, then GCP altitude will be used in reconstruciton instead of exif metadata. you can always edit the gpsaltitude of the exif data with exiftool or geosetter.
3 Likes
I don’t know if there was any talk about this in private, but I didn’t see any mention of this: I just checked the nearest geodetic survey marker and geoid separation for the area is around -27m. Add this to the average between 13 and 35 from your ODM output and it gives you 49m orthometric. Are you sure it’s not as simple as this? One piece of software transforming from ellipsoidal to orthometric and not the other?
I normally would assume you considered this already knowing your experience, but we never know.
1 Like
Thanks to Uplanddog and Gabriel for your comments.
This was not my data and I made some calls and found out some users are no longer using base stations. That being said, drone elevation, when not using an accurate base station, is marked from AGL and not MSL as Uplanddog stated. So, I ran my own test with an Evo II Pro RTK unit and was able to get much closer. No base station is required for the majority of my work. I converted the DTM from WebODM as follows. I multiplied the raster DTM by 3.2808 to convert to feet. Then, found the nearest benchmark and added 66 feet in my case only to get to the correct elevation per USGS. Not 100%, but the volumes are accurate relative to themselves. Imagine taking an upside down paper cup sitting on your desk and moving it up or down along the Z-axis. The volume in the cup remains the same as the elevation changes. QGIS has a “raster calculator” that makes it very easy to update. My final test will be to cross-check volumes between QGIS, ArcGIS Pro, and WebODM. Stay tuned…
Thanks again all!!!
Gerry
4 Likes
