Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Read multiple resolutions to deal with data voids #74

Open
jpolchlo opened this issue Apr 2, 2020 · 0 comments
Open

Read multiple resolutions to deal with data voids #74

jpolchlo opened this issue Apr 2, 2020 · 0 comments

Comments

@jpolchlo
Copy link
Contributor

jpolchlo commented Apr 2, 2020

When a data void is encountered, we can currently experience some bad behaviors in our DEM generation. For the example case of a point cloud and extent pairing that appears as the illustration below, we will get an improper DEM result. The DEM will be confined to the area containing the points, and the right side of the result will be empty.

 * ** *** *** * *  *  * *   *
* * * *  **  * * * ** *** * *
* **          * **  ** * *  **
+------------+   * ** * * * *
|*  *        |   * * * * * * *
| **         |   *** *** * **
|* ***       |    * * *** *  *
+------------+   **  ** *  * *
* * * *  * *   * * *** * * **
  ** * ***  * * * *  ** * * **

For gap filling to work, points on all sides of the gap need to be included in the sample. We had originally intended to push development on PDAL to use the EPT tree to supply this multiresolution sample (see #54), but that effort was shut down by the PDAL team (understandably) seeing limited utility of the required option. We thus have to simulate the feature using multiple readers covering different extents at different resolutions.

We can use a sequence (of at least two) readers of the following description: The first reader will grab the requested region at full resolution, the last reader will grab the entire 0-0-0-0 node by requesting the full EPT extent at very large resolution. Any number of intermediate reads can be performed with extent sizes/cell sizes between the top- and bottom-level queries.

This implies a performance penalty for triangulating a larger number of points, but may also cause other difficulties from each read having overlapping points (some of the points in the 0-0-0-0 node will also be contained in all other requests) if this isn't dealt with intelligently by PDAL. (Delaunay triangulation doesn't take kindly to repeated points.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant