QGIS 3.18 and ODM-generated EPTs #1237
Labels
Comments
|
That seems strange; a missing Z-value would imply that the EPT cannot be opened in Potree/WebODM also (but it can). That said, ODM probably used Entwine (not Untwine) to generate the EPT dataset, we use Untwine only as a fallback if an out-of-memory error happens. The two should produce comparable EPT data though, so it shouldn't matter. I would start debugging by trying to regenerate the EPT dataset manually (using the version of entwine provided with ODM, then try untwine, then switch to a standalone version of entwine, and finally a standalone version of untwine). |
|
Got this feedback from Martin Dobias on the test EPT from ODM:
|
|
Cool, perhaps entwine needs to be updated then. |
I'll try to tackle this in the coming week or so. |
Looking at Entwine/Untwine, it looks like we're already targeting the latest Entwine, right? And we're using your fork of Untwine, as well. Does that contain changes that the upstream Hobu Untwine doesn't have? |
I took a look whether there are flags for generating stats, and there's nothing: a strong indication that it generates them if a new enough version is used. Glad you'll be working on this, and thanks for troubleshooting with Lutra: super cool to see this in Q... . I wonder if it will fix this issue: |
|
For whatever reason the EPT I generated on my machine for brighton works OK. (From ODM using
|
|
That's super strange... It is missing the values that Martin said it should have. |
|
And this one is generated with untwine (also from ODM):
|
|
Hi, sorry the "missing Z values" was an incorrect finding - the Z values are present as they should be :-) The only missing thing, as mentioned in the mail, is that the generated EPT does not include statistics. Not sure if ODM uses Entwine or Untwine (or both?) - but either has an option to include statistics for each dimension. This is extremely helpful for QGIS as we then know what are the valid ranges of dimensions and can pre-configure 2D/3D rendering to look good out of the box... |
Piero has stated that it uses Entwine by default unless we get an out of memory situation, in which case it'll switch to Untwine. (#1237 (comment)) Do you happen to have a link to specs or an example with those properly formed JSON files containing all the extra stats for proper QGIS display? |
|
@Saijin-Naib can you upload your ept.json somewhere also? |
|
This is the EPT.JSON that was in the Living Room sample data that Martin/Saber were poking at. |
Here's an example with and without stats in ept.json for the same source file: Unfortunately the statistics are not described in the official EPT docs: https://entwine.io/entwine-point-tile.html |
Nope: those don't look like they are in the same place. Your error is just smaller than mine maybe because I have a whole city of point cloud and you have a picnic area. 😺 I'm forever taking small errors and turning into big ones. That's my function signature. |
|
Georeferencing offset problems aside, it's strange my EPT dataset displays on the map, because it doesn't have statistics either. Full dataset included here: |
QGIS is able to load EPT datasets also when statistics are missing, the user experience is just not as smooth. In QGIS we use those statistics mainly to know min-max ranges for Z and other dimensions - so for example in your dataset when I wanted to use "Attribute by ramp" rendering style based on Z, it took me a some trial and error that the usable range is somewhere around 150-180:
With point clouds with RGB this shortcoming is maybe less obvious than with non-colorized lidar data where we can't default to RGB renderer. Maybe we will add also a "load min/max from the current map view" button to estimate the ranges - but we don't have that yet... |
|
That makes sense :) Thanks for the clarification @wonder-sk ! |
|
If it's useful, I have a dataset that if I try to access properties in QGIS crashes it every time (on PopOS anyway). |
|
@smathermather I think the crash when opening layer properties should be already fixed - see qgis/QGIS#41722 - hopefully we will get 3.18.1 out soon with this and some other fixes. Or you can compile QGIS from git master for the time being... |
|
Ah, perfect. Glad it was already found. |
|
I have another LAS/LAZ dataset that doesn't generate a proper EPT in QGIS when being previewed: |
@Saijin-Naib I have just tried it and this is a known issue in untwine when scale of X/Y/Z coordinates is ridiculously low - see hobuinc/untwine#53 (comment) |
|
These data are apparently directly out of a Faro S70 Laser Scanning Unit, a fairly high-end piece of kit, via AutoDesk ReCap. |
|
Closing, as this doesn't seem to be a bug in ODM per-se, just a data input workflow. |
3 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
In testing EPTs generated by ODM, I came across an issue with them displaying properly within QGIS 3.18.x with PDAL support.
I've provided sample data to Saber Razmjooei/Lutra Consulting, and they indicated that the ODM-generated EPT they tested did not have any Z-data, but the accompanying LAZ files did.Is there anything in our process that might lead to Z-Values being dropped from EPTs during generation?The text was updated successfully, but these errors were encountered: