[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 <andrew.bell.ia at gmail.com> wrote:

>
>
> On Fri, Nov 8, 2019 at 11:18 AM Andrew Cunliffe <andrewmcunliffe at gmail.com>
> wrote:
>
>> Can anyone help with the syntax to calculate HAG (height above ground)
>> relative to an interpolated surface (following James McClain’s
>> contribution, #2520 <https://github.com/PDAL/PDAL/pull/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
> andrew.bell.ia at gmail.com
>


-- 
Dr Andrew Cunliffe

Research Fellow in Dryland Carbon Dynamics
School of Geography, College of Life and Environmental Science,
University of Exeter

UoEx Profile
<http://geography.exeter.ac.uk/staff/index.php?web_id=Andy_cunliffe>
Google Scholar
<https://scholar.google.co.uk/citations?user=GEfm3PIAAAAJ&hl=en>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20191111/4dbd747b/attachment.html>