[pdal] [pgpointcloud] ply and laz

Fri Sep 25 15:30:25 PDT 2015

Classification: UNCLASSIFIED
======================================================

Hi Howard,

I work with Dean.

Actually, we're getting errors when reading the pdal produced ply files into Meshlab.  This may not be a pdal problem, though, so I'm not going to detail that error.  However, in trying to diagnose, we implimented the "ascii" instead of "little endian" storage mode (i.e., <Option name="storage_mode">ascii</Option>), so our pipeline is more like this:

<?xml version="1.0" encoding="utf-8"?>
<Pipeline version="1.0">
    <Writer type="writers.ply">
        <Option name="filename">/mydir/outputfile.ply</Option>
        <Option name="storage_mode">ascii</Option>
        <Option name="spatialreference">EPSG:4326</Option>
        <Reader type="readers.pgpointcloud">
            <Option name="connection">host='localhost' dbname='lidar' user='pramsey'</Option>
            <Option name="table">pcgen</Option>
            <Option name="column">pa</Option>
            <Option name="where">PC_Intersects(pa, ST_MakeEnvelope(56.003736, 51.1484645, 56.266731, 51.1894324, 4326))</Option>
        </Reader>
    </Writer>
</Pipeline>

When we import an LAS file into QT Modeler that was created by using writers.las instead of writers.ply in the above pipeline (with some scaling options), the point cloud data looks fine, so we know that the point cloud database has the necessary level of precision.  But, when we use the writers.ply (with ascii storage_mode), the output ply file has only 4 digits of precision following the decimal point as follows:

ply
format ascii 1.0
element vertex 12345
property float64 X
property float64 Y
property float64 Z
property uint16 Intensity
...
end_header
56.0037 51.1484 12.123 25 ...
56.0037 51.1484 13.423 28 ...
56.0037 51.1485 15.153 40 ...
56.0038 51.1485 33.126 37 ...
56.0038 51.1485 12.723 125 ...
56.0038 51.1486 12.183 115 ...

By the way, we also have a simialr problem when trying to output a CSV file using writers.text except in that case there are only 3 digits of precision following the decimal, so output is like:

"X","Y","Z","Intensity",...
56.004,51.148,12.123,25.000,...
56.004,51.148,13.423,28.000,...
56.004,51.149,15.153,40.000,...
56.004,51.149,33.126,37.000,...
56.004,51.149,12.723,125.00,...
56.004,51.149,12.183,115.00,...

We need at least 6 digits of precision for the X and Y values in both of these scenarios (yielding 0.1 meter resolution for EPSG 4326 values), but having an option to define the precision for the various columns would be optimal.

-Jim

-----Original Message-----
From: Hand Dean NGA-II USA CTR
Sent: Friday, September 25, 2015 3:02 PM
To: Greenlee James -Jim- V NGA-IIG USA CTR
Subject: FW: [pgpointcloud] ply and laz

Classification: UNCLASSIFIED
======================================================

-----Original Message-----
From: Hand Dean NGA-II USA CTR
Sent: Friday, September 25, 2015 2:29 PM
To: 'Howard Butler'
Cc: pgpointcloud at lists.osgeo.org<mailto:pgpointcloud at lists.osgeo.org>; pdal
Subject: RE: [pgpointcloud] ply and laz

Classification: UNCLASSIFIED
======================================================

We are using PDAL.  There is a writers.ply, but did doesn't say what readers it will support.  We are using something similar to this xml:

<?xml version="1.0" encoding="utf-8"?>
<Pipeline version="1.0"><Pipeline version="1.0">
  <Writer type="writers.ply">
    <Option name="filename">outputfile.ply</Option>
    <Option name="storage_mode">little endian</Option>
    <Reader type="readers.pgpointcloud">
      <Option name="connection">dbname='lidar' user='user'</Option>
      <Option name="table">lidar</Option>
      <Option name="column">pa</Option>
      <Option name="spatialreference">EPSG:26910</Option>
      <Option name="where">
        PC_Intersects(pa, ST_MakeEnvelope(560037.36, 5114846.45, 562667.31, 5118943.24, 26910))
      </Option>
    </Reader>
  </Writer>
</Pipeline>

-----Original Message-----
From: Howard Butler [mailto:howard at hobu.co]
Sent: Friday, September 25, 2015 2:21 PM
To: Hand Dean NGA-II USA CTR
Cc: pgpointcloud at lists.osgeo.org<mailto:pgpointcloud at lists.osgeo.org>; pdal
Subject: Re: [pgpointcloud] ply and laz

> On Sep 25, 2015, at 2:04 PM, Dean.Hand.ctr at nga.mil<mailto:Dean.Hand.ctr at nga.mil> wrote:
>
> Classification: UNCLASSIFIED
> ======================================================
>
> Hi Howard,
>
> When trying to pgpointcloud to write as either a ply we're experiencing an issue.  For ply files, the x and y coordinates are only 3 digits in length. I don't see anything in our docs to explain this...
>
> Can you please help?

I don't think pgpointcloud supports writing natively as ply? Are you using PDAL?

If so:

* What do you mean by "digits"? Do you mean digits after the decimal point?
* What was original source data format before it went into pgpointcloud? LAS
* It is possible that the PDAL ply driver could be modified to support overriding the output precision, but some investigation would need to be done into the rply code that PDAL uses to read/write PLY. Quickly looking at the PDAL source. this feature doesn't appear to exist yet.

Howard

======================================================
Classification: UNCLASSIFIED

======================================================
Classification: UNCLASSIFIED

======================================================
Classification: UNCLASSIFIED