[pdal] Syntax for implementing new filters.hag relative to TIN

Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[pdal] Syntax for implementing new filters.hag relative to TIN

Andrew Cunliffe

Can anyone help with the syntax to calculate HAG (height above ground) relative to an interpolated surface (following James McClain’s contribution, #2520)?


I’ve tried:

{

    "type": "filters.hag",

    "delaunay": True

},

 

But the output HAG is clearly still being computed relative to the nearest neighbour, rather than an interpolated surface as desired.  I’ve tried "delaunay_fan": True, and also including “count”: 4 arguments, and have been looking through GitHub (which led me to “delauney” rather "delaunay_fan") but still haven’t succeeded.


What am I missing?


Thanks,

Andy


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

Re: [pdal] Syntax for implementing new filters.hag relative to TIN

andrew.bell.ia@gmail.com


On Fri, Nov 8, 2019 at 11:18 AM Andrew Cunliffe <[hidden email]> wrote:

Can anyone help with the syntax to calculate HAG (height above ground) relative to an interpolated surface (following James McClain’s contribution, #2520)?


I’ve tried:

{

    "type": "filters.hag",

    "delaunay": True

},

 

But the output HAG is clearly still being computed relative to the nearest neighbour, rather than an interpolated surface as desired.  I’ve tried "delaunay_fan": True, and also including “count”: 4 arguments, and have been looking through GitHub (which led me to “delauney” rather "delaunay_fan") but still haven’t succeeded.


The option is "delaunay", as you've specified, though the constant 'true' must be specified in lowercase to be valid JSON. 

What am I missing?

Looking at the code, it appears that you also need to set "count" to some reasonable value in order to get this interpolation method to work.  The code builds a delaunay triangulation of <count> neighbors and then interpolates attempts to use that triangulation to determine a Z value for the point in question.  I'd have to look through the math more closely to give you better information.  It appears that things haven't been documented.  I'll take a stab at that before long.

--
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] Syntax for implementing new filters.hag relative to TIN

Andrew Cunliffe
Thanks for the help Andrew,

Unfortunately this pipeline {"type": "filters.hag", "count": 4, "delaunay": 'true'}, is still throwing exceptions (non-zero Python exit code).

I can imagine setting a larger count (e.g. 20-30) reduces the likelihood that the point under consideration lies beyond the interpolated TIN surface, but is it not possible to create a TIN from  3 ground points? (Shouldn't this be fine as long as all the non-ground points lie within the extent of the triangle?)

In my application, all non-ground points lie within an area bounded by 4 ground points (after filters.crop). Supplying {"type": "filters.hag",  "count": 1,  "delaunay": 'true' } executes nearest neighbour (which is logical), but any other number of count (2, 3, 4, 5, 10 ,20, 30) returns a non-zero exit code.

Thanks for any more tips,
Andy





On Fri, 8 Nov 2019 at 18:51, Andrew Bell <[hidden email]> wrote:


On Fri, Nov 8, 2019 at 11:18 AM Andrew Cunliffe <[hidden email]> wrote:

Can anyone help with the syntax to calculate HAG (height above ground) relative to an interpolated surface (following James McClain’s contribution, #2520)?


I’ve tried:

{

    "type": "filters.hag",

    "delaunay": True

},

 

But the output HAG is clearly still being computed relative to the nearest neighbour, rather than an interpolated surface as desired.  I’ve tried "delaunay_fan": True, and also including “count”: 4 arguments, and have been looking through GitHub (which led me to “delauney” rather "delaunay_fan") but still haven’t succeeded.


The option is "delaunay", as you've specified, though the constant 'true' must be specified in lowercase to be valid JSON. 

What am I missing?

Looking at the code, it appears that you also need to set "count" to some reasonable value in order to get this interpolation method to work.  The code builds a delaunay triangulation of <count> neighbors and then interpolates attempts to use that triangulation to determine a Z value for the point in question.  I'd have to look through the math more closely to give you better information.  It appears that things haven't been documented.  I'll take a stab at that before long.

--
Andrew Bell
[hidden email]


--
Dr Andrew Cunliffe

Research Fellow in Dryland Carbon Dynamics

School of Geography, College of Life and Environmental Science,
University of Exeter



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

Re: [pdal] Syntax for implementing new filters.hag relative to TIN

andrew.bell.ia@gmail.com


On Mon, Nov 11, 2019, 06:12 Andrew Cunliffe <[hidden email]> wrote:
Thanks for the help Andrew,

Unfortunately this pipeline {"type": "filters.hag", "count": 4, "delaunay": 'true'}, is still throwing exceptions (non-zero Python exit code).

I can imagine setting a larger count (e.g. 20-30) reduces the likelihood that the point under consideration lies beyond the interpolated TIN surface, but is it not possible to create a TIN from  3 ground points? (Shouldn't this be fine as long as all the non-ground points lie within the extent of the triangle?)

Yes, but you have to choose the"right" points. I may be able to change things so that this parameter isn't necessary. If you can share your data, I'd love to use it as a test case and to experiment with the issue you're having.


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

Re: [pdal] Syntax for implementing new filters.hag relative to TIN

James McClain-2
Hello,

It isn't necessarily the case that the parameter will be low for any given dataset.  For example, if you have a dataset with recognizable scan lines with a relatively small distance between subsequent samples, but the scan lines are relatively far apart.

A workable parameter-free approach would definitely be superior to what is currently there, though.

Sincerely,
James McClain



On Mon, Nov 11, 2019 at 7:52 AM Andrew Bell <[hidden email]> wrote:


On Mon, Nov 11, 2019, 06:12 Andrew Cunliffe <[hidden email]> wrote:
Thanks for the help Andrew,

Unfortunately this pipeline {"type": "filters.hag", "count": 4, "delaunay": 'true'}, is still throwing exceptions (non-zero Python exit code).

I can imagine setting a larger count (e.g. 20-30) reduces the likelihood that the point under consideration lies beyond the interpolated TIN surface, but is it not possible to create a TIN from  3 ground points? (Shouldn't this be fine as long as all the non-ground points lie within the extent of the triangle?)

Yes, but you have to choose the"right" points. I may be able to change things so that this parameter isn't necessary. If you can share your data, I'd love to use it as a test case and to experiment with the issue you're having.

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


--
James McClain
Software Developer
Azavea  |  990 Spring Garden Street, 5th Floor, Philadelphia, PA 19123


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