[pdal] Pgpointcloud writer SRID

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[pdal] Pgpointcloud writer SRID

Lars
Hello,

We used a pipeline (see attched file) to read a laz file and write it to pgpointcloud. The pipeline was able to write data to database but we notice the SRID was incorrect. Turns out the laz was using UTM Zone and pgpointcloud used 4326 (the default). By adding a reprojection filter to the pipeline we were able to fix the issue.

We mistakenly thought that pgpointcloud would "reproject" the input data to srid 4326 but it makes sense the this task belongs in a filter.

It is unfortunte that PDAL allowed us to create what I consider is invalid data which could have been prevented. The "srid" parameter used in the pipeline appears to be a string with sole purpose of being added to the pointcloud_formats table. In pgpointcloud witer, would it be possible to use input-srid (in_srs) as default if available instead of always using 4326? Another option could be to give the user a warning if input-srs does not match the "srid" specified for pgpointcloud writer.

It might be worth adding more information about pgpointcloud writer "srid" to the documentation to help others.

Kind regards, Lars


_______________________________________________
pdal mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pdal
Reply | Threaded
Open this post in threaded view
|

Re: [pdal] Pgpointcloud writer SRID

andrew.bell.ia@gmail.com
There is no attached file, so it's hard to see what the issue might be.  Please just reply with the pipeline in question.

Thanks,

On Fri, Jul 6, 2018 at 7:33 AM, Lars <[hidden email]> wrote:
Hello,

We used a pipeline (see attched file) to read a laz file and write it to pgpointcloud. The pipeline was able to write data to database but we notice the SRID was incorrect. Turns out the laz was using UTM Zone and pgpointcloud used 4326 (the default). By adding a reprojection filter to the pipeline we were able to fix the issue.

We mistakenly thought that pgpointcloud would "reproject" the input data to srid 4326 but it makes sense the this task belongs in a filter.

It is unfortunte that PDAL allowed us to create what I consider is invalid data which could have been prevented. The "srid" parameter used in the pipeline appears to be a string with sole purpose of being added to the pointcloud_formats table. In pgpointcloud witer, would it be possible to use input-srid (in_srs) as default if available instead of always using 4326? Another option could be to give the user a warning if input-srs does not match the "srid" specified for pgpointcloud writer.

It might be worth adding more information about pgpointcloud writer "srid" to the documentation to help others.

Kind regards, Lars


_______________________________________________
pdal mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pdal



--
Andrew Bell
[hidden email]

_______________________________________________
pdal mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pdal
Reply | Threaded
Open this post in threaded view
|

Re: [pdal] Pgpointcloud writer SRID

Lars
{
  "pipeline": [
    {
      "type": "readers.las",
      "filename": "c:\\tmp\input.laz"
    },
    {
      "type":"filters.chipper",
      "capacity":5000
    },
    {
      "type": "writers.pgpointcloud",
      "connection": "host=...",
      "table": "test_1",
      "compression":"none",
      "output_dims":"X,Y,Z"
    }
  ]
}



Fra: Andrew Bell <[hidden email]>
Sendt: fredag 6. juli 2018 16.06
Til: Lars
Kopi: [hidden email]
Emne: Re: [pdal] Pgpointcloud writer SRID
 
There is no attached file, so it's hard to see what the issue might be.  Please just reply with the pipeline in question.

Thanks,

On Fri, Jul 6, 2018 at 7:33 AM, Lars <[hidden email]> wrote:
Hello,

We used a pipeline (see attched file) to read a laz file and write it to pgpointcloud. The pipeline was able to write data to database but we notice the SRID was incorrect. Turns out the laz was using UTM Zone and pgpointcloud used 4326 (the default). By adding a reprojection filter to the pipeline we were able to fix the issue.

We mistakenly thought that pgpointcloud would "reproject" the input data to srid 4326 but it makes sense the this task belongs in a filter.

It is unfortunte that PDAL allowed us to create what I consider is invalid data which could have been prevented. The "srid" parameter used in the pipeline appears to be a string with sole purpose of being added to the pointcloud_formats table. In pgpointcloud witer, would it be possible to use input-srid (in_srs) as default if available instead of always using 4326? Another option could be to give the user a warning if input-srs does not match the "srid" specified for pgpointcloud writer.

It might be worth adding more information about pgpointcloud writer "srid" to the documentation to help others.

Kind regards, Lars


_______________________________________________
pdal mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pdal



--
Andrew Bell
[hidden email]

_______________________________________________
pdal mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pdal
Reply | Threaded
Open this post in threaded view
|

Re: [pdal] Pgpointcloud writer SRID

Howard Butler-3


On 7/11/18 1:39 AM, Lars wrote:
> We used a pipeline (see attched file) to read a laz file and write it to pgpointcloud. The pipeline was able to write data to database but we notice the SRID was incorrect. Turns out the laz was using UTM Zone and pgpointcloud used 4326 (the default). By adding a reprojection filter to the pipeline we were able to fix the issue.

PDAL refuses the temptation to guess. It is very difficult to detect
that two coordinate systems are "different", and automatically infer
your intention, even in this scenario.

> We mistakenly thought that pgpointcloud would "reproject" the input data to srid 4326 but it makes sense the this task belongs in a filter.
>
> It is unfortunte that PDAL allowed us to create what I consider is invalid data which could have been prevented. The "srid" parameter used in the pipeline appears to be a string with sole purpose of being added to the pointcloud_formats table. In pgpointcloud witer, would it be possible to use input-srid (in_srs) as default if available instead of always using 4326? Another option could be to give the user a warning if input-srs does not match the "srid" specified for pgpointcloud writer.

Deconstructing a coordinate system defined by WKT or GeoTIFF keys to a
single authoritative EPSG code is a task that is rarely successful in an
automated fashion. We are unable to take the SRS and assign a single
value for the "srid" to the output data. Again, we refuse the temptation
to guess, and that is why there's a parameter on the writer for users to
assign what they need.  Maybe some more docs related to the topic would
help, but this is a challenge for all of PDAL's writers, not just
pgpointcloud.

> It might be worth adding more information about pgpointcloud writer "srid" to the documentation to help others.

We would be happy to merge a patch that added such experience and
documentation. Please file a ticket with language you think would be
most helpful.

Howard



_______________________________________________
pdal mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/pdal

signature.asc (540 bytes) Download Attachment