[pdal] DEM Grids - p2g bounding box

[Bradley Chambers]

I've not worked with this specific feature, but if it's already in P2G, the
plugin enhancement to pass the parameter should be trivial.

Brad

On Tue, Mar 24, 2015 at 11:58 AM, Matthew Hanson <
mhanson at appliedgeosolutions.com> wrote:

> Pete - this looks like exactly what I need!   At least on the p2g side.
> Now, what's the best way to incorporate this into the PDAL plugin?
>
> Andrew, the problem with setting the bounds after the fact is that the
> calculated grid could be shifted by fractional pixels from the desired
> one.  So you really need to be able to specify the starting grid so that
> your end result has properly interpolated at the pixel centers you'll want
> to use.
>
> Matthew Hanson
> Applied GeoSolutions
> (603) 659-3363 x91
> http://appliedgeosolutions.com
> mhanson at appliedgeosolutions.com
>
>
> On Tue, Mar 24, 2015 at 11:48 AM, <pete.gadomski at gmail.com> wrote:
>
>> Matthew,
>>
>> We added the ability to specify a user-defined grid in Points2Grid a few
>> months ago, thanks to work by Tristan Dyer.
>> https://github.com/CRREL/points2grid/commit/b2ada6abfc85560ec10fb4f30333a1bf95be9025.
>> Is that what you had in mind?
>>
>> -Pete
>>
>>
>>
>> On Tue, Mar 24, 2015 at 10:41 AM, Matthew Hanson <
>> mhanson at appliedgeosolutions.com> wrote:
>>
>>> We've run into another little snag trying to create DEMs.    I made a
>>> commit last month to fix the half pixel offset in p2g output:
>>>
>>> https://github.com/PDAL/PDAL/commit/ea67d14f43b09e591ef94c7f03ef75d64dc786ed
>>>
>>> Which is correct, the output is not correctly aligned to how it's doing
>>> the gridding, however the gridding itself isn't really ideal.   There are 2
>>> problems:
>>>
>>> 1) p2g uses the upper left point (min x, max y) as the *center* of the
>>> top left pixel.   So this means that there are going to always be fewer
>>> points to choose from when on a corner of edge of the resulting raster.
>>> How many fewer points depends on the search radius.    While this depends
>>> on the output of the raster (e.g., min, max, idw) this might not be
>>> noticeable at all, but there are certainly some edge effects from this.
>>> Granted if p2g used half a pixel in from the minx/maxy point it could still
>>> suffer from this problem if given a search radius > 0.5 pixel, but I think
>>> we can agree that the using the top left available point as the center of
>>> the pixel is not the best way.
>>>
>>> 2) Related to the above problem is the more general one that the raster
>>> bounding box is completely reliant on the input point cloud.    When using
>>> point clouds that have been tiled, or otherwise have specifically chosen
>>> bounds (but perhaps points do not go all the way to the edge) the output
>>> raster may not have the same bounding box.   However, the even greater
>>> problem is that if you create a DTM from ground points and a DSM from
>>> non-ground...well, that top left point is going to be different between
>>> those and therefore you get two DEM rasters that are potentially on
>>> completely different grids.
>>>
>>> What is really needed, and would solve both issues in a general way, is
>>> to be able to specify the grid that should be used (really this just means
>>> being able to give it an exact top left coordinate).    This would allow
>>> alignment of DTM and DSM without requiring postwarping (really not
>>> desirable).
>>>
>>> It looks like this would mostly be a change within p2g to take in a
>>> starting x,y coordinate, and in PDAL the addition of another argument to
>>> pass to OutCoreInterp.
>>>
>>> Does this seem like desirable behavior?
>>>
>>>
>>>
>>> Matthew Hanson
>>> Applied GeoSolutions
>>> (603) 659-3363 x91
>>> http://appliedgeosolutions.com
>>> mhanson at appliedgeosolutions.com
>>>
>>>
>>
>
> _______________________________________________
> pdal mailing list
> pdal at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pdal
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/pdal/attachments/20150324/abaae3b3/attachment.html>