SPRT precision mode

Deprecated Sequoia Beta Bug Reports
1

It seems pretty quite so I’m not sure if this forum is still the right place to report bugs, but I can’t seem to get the higher precision SPRT storage working with version 1.1.9.06fae4c (or 1.1rc40.5955fe6).

I have a georeferenced text file (UTM meters) with x, y, z, and intensity. The first few lines are:

233268.700 3994768.682 1876.327 208 233268.724 3994768.681 1876.267 220 233268.294 3994768.658 1875.685 222 233268.300 3994768.657 1875.624 226 233268.284 3994768.656 1875.562 212 233268.283 3994768.655 1875.501 222 233268.310 3994768.655 1875.442 221 233268.328 3994768.644 1874.775 226 233268.335 3994768.643 1874.714 222 233268.345 3994768.642 1874.654 217
I add a point loader and as expected the preview shows banding due to rounding errors. Next I run the precision analysis with the SPRT mode set to Automatic and it correctly detects the bounds of the data set and suggests Single+Offset storage. If I build the SPRT Cache the log window reports:

[12:17:44] STS: Saving SPRT in single precision mode

With the cache loaded I still have banding due to precision loss, suggesting the log is telling the truth. If I turn off the automatic SPRT mode and manually set it the log always reports that the SPRT is being saved in single precision mode, regardless of whether I choose ‘single’, ‘single+offset’, or ‘double’.

2

Hi Jed,

This is still a good place to report bugs, we see all the posts here! We can reproduce this, the bug appears to be triggered when the column selection dialog gets used. We’ll log this and fix it ASAP, thanks!

-Mark

3

It looks like there may be another, perhaps related issue. If I use the batch converter and choose double as the output precision everything works fine. However, if I choose single+offset I still end up with sprt with precision issues, even though the log reports that the sprt is being saved in single+offset mode.

4

Hi Jed,

What you’ve found is another unrelated issue, the lower level of details in the SPRT saving weren’t getting the correct offset applied, thus didn’t have correct precision matching the highest level of detail. We’ve fixed both of these issues and will post a new build with them after release testing.

Thanks,
Mark

5

Great, thanks.

6

A build with these fixes, 1.1.12, has been uploaded to box.

-Mark