Skip to content
This repository has been archived by the owner on Apr 27, 2021. It is now read-only.

north, south, east, west not clearly defined #6

Open
mankoff opened this issue Jun 16, 2013 · 2 comments
Open

north, south, east, west not clearly defined #6

mankoff opened this issue Jun 16, 2013 · 2 comments

Comments

@mankoff
Copy link
Contributor

mankoff commented Jun 16, 2013

Given a small sample input file like:

0,0,10
10,10,10

and running p2g with a very large search radius and resolution, one would expect a single output point with a min, mean, and max of 10. This works. But what is the definition of north, south, east, and west in this case?

The output file says they are all 10, but I would expect them to be the cell edges [0,10] or cell center 5.

@mankoff
Copy link
Contributor Author

mankoff commented Jun 16, 2013

Related to #7 and better described there, although that bug report focuses on the Z value, whereas this focuses on the N/S/E/W values.

@gadomski
Copy link
Contributor

I'm not sure if the cell edges should be [0, 10] in this case — if you're specifying a very large resolution (you used 1e4 in other issues, e.g. #5), shouldn't the cell edges be controlled by that resolution?

However, I'm going to keep this issue open, since the definition of proper behavior for your example is poorly defined. I agree that it probably should be something sane (centered on the centroid of the points? using the min point as the lower left?), and right now it's very arbitrary how this is handled.

gadomski referenced this issue in gadomski/PDAL May 4, 2015
I don't trust that p2g is handling these bounds in a sane way, so I have
to go dig into that to see what's going on.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants