[pdal] [pgpointcloud] ply and laz

Mon Sep 28 10:20:15 PDT 2015

All,

It looks like rply just uses fprintf with %g (
https://github.com/PDAL/PDAL/blob/master/vendor/rply-1.1.3/rply.c#L1303)
when doing ascii output. Looks like we'd have to patch the vendored rply
code to change that.

IMO ply's ascii output isn't very useful, as it's very space-inefficient.
If folks need to print out point values as text they should probably use
the text writer (which does provide a mechanism for specifying decimal
precision,
https://github.com/PDAL/PDAL/blob/master/io/text/TextWriter.cpp#L114). Maybe
we should remove the ascii option for the ply writer to avoid this problem
in the future? Thoughts?

-Pete

On Mon, Sep 28, 2015 at 10:38 AM <James.V.Greenlee.ctr at nga.mil> wrote:

> 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
>
>
> _______________________________________________
> pdal mailing list
> pdal at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pdal
>
-- 
Pete Gadomski
Physical Scientist
Cold Regions Research and Engineering Laboratory
530.440.4630
pete.gadomski at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20150928/432abc8d/attachment.html>