I check pdal info and see that bbox has 15 digit numbers:

"boundary": { "type": "Polygon", "coordinates": [ [ [ 1528634.540273188613355, 403421.710437842586543, 234.984 ], [ 1528634.540273188613355, 407979.483437842573039, 234.984 ], [ 1528834.540273188613355, 407979.483437842573039, 315.504 ], [ 1528834.540273188613355, 403421.710437842586543, 315.504 ], [ 1528634.540273188613355, 403421.710437842586543, 234.984 ] ] ] }

Then I imported this las file into pgpointcloud with this pipeline.json:

        "pipeline": [
                "type": "writers.pgpointcloud",

The scheme in pointcloud_formats:

  <pc:description>X coordinate</pc:description>
  <pc:description>Y coordinate</pc:description>

And finally coordinates in table

with pts as(
    select PC_Explode(pa) as pt
    from "Blocks"
    where id = 100000
     PC_Get(pt, 'X') as "x"
    ,PC_Get(pt, 'Y') as "y"
from pts
order by PC_Get(pt, 'Z');
x                   y
1531507.46827319    404533.469437843
1531507.47027319    404533.577437843

So in imported table precision is 8 digit numbers.

After I added both, the table and the las file in QGIS and found that the same point very very close but not exactly the same.

So did I lose precision? And how to prevent this?

  • 5
    The original numbers have 15 decimals and only 12 decimals are needed to express the diameter of a helium atom en.wikipedia.org/wiki/Picometre.
    – user30184
    Commented Mar 29, 2022 at 15:41
  • @user30184 Well it's make sense but i just can't find a reason why my points move. And is it normal behavior or not.
    – Kliver Max
    Commented Mar 29, 2022 at 15:52

3 Answers 3


You can preserve the precision by setting the scale factors in the point cloud writer, try adding these just below "type": "writers.pgpointcloud" :


From the docs: enter image description here

Function docs: https://pdal.io/stages/writers.pgpointcloud.html

  • Any manipulations with scale_x/scale_y gives me error: Unable to convert double to int32 for packed DB output: X: (1.52877e+21).
    – Kliver Max
    Commented Mar 29, 2022 at 15:51
  • I think this has something to do with the output format you are using. Can you try changing to "type": "writers.las" and see if the problem persists? If not, one could assume the limitation is the the data type for your coordinate fields, which you can set manually in the schema as shown here: pgpointcloud.github.io/pointcloud/concepts/schemas.html
    – Kartograaf
    Commented Mar 29, 2022 at 16:14

Bounding boxes are stored as double in a LAS files. But the point cloud coordinates are stored as integer and converted to double with a scale factor and an offset. It means that the point cloud coordinates are stored with a given accuracy (typically 2 decimals) but the bounding box could not conform to the standard and be stored with an irrelevant accuracy that does not match with the point cloud. I think your file does not conform to ASPRS standard but I may be wrong without seeing the file.

Anyway as mentioned in comments your accuracy is subatomic

  • Well, the precision is sub-ångström, but I doubt the accuracy is.
    – Vince
    Commented Mar 12 at 18:25

The problem is that PDAL is not conserving the previous offset, the default value for offset is 0 (source: PDAL las.writers page). This end up in it trying to save untranslated coordinates, which force it to drop some some significant values as the coordinates are too big. To correct it, you need to make PDAL offset the pointcloud when saving it.

If in command line, add :

--writers.las.offset_x=auto --writers.las.offset_y=auto --writers.las.offset_z=auto

if json pipeline, add to the writers.las :


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.