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

Viewshed Multiple Observer Heights #804

Open
harrisonjkaplan opened this issue Aug 29, 2024 · 5 comments
Open

Viewshed Multiple Observer Heights #804

harrisonjkaplan opened this issue Aug 29, 2024 · 5 comments

Comments

@harrisonjkaplan
Copy link

Author of Proposal:
Harrison K

Reason or Problem

For a given observer location, I would like to know at what height a given observable point is visible.

Proposal

viewshed() would take another parameter in addition to observer_elev, that specifies a max_height to calculate to, if the max_height is less than observer_elev a value error is raised. When each point's visibility relative to the observer is evaluated, the function would iteratively check against increasing values until the max_height.

Design:
A new optional parameter of max_height would need to be added, another for step size could also be added to specify by how much the height should increase for each iteration of recalculation. After comparing a given points angle, if the point is determined to be invisible, the height will be incremented and then the angle will be recalculated and compared again. I am still not sure on the best way of storing the height results.

Usage:
User would provide a max_height parameter, without this parameter the current functionality will remain the same.

Value:
User's of viewshed() would have a way of leveraging the existing calculation capabilities, while expanding giving them the ability to run calculations for multiple observer heights simultaneously.

Stakeholders and Impacts

I am happy to develop this feature myself after getting some more input, specifically on how the results should be returned. For those already using viewshed() this feature should not impact their use at all. Onlyviewshed() will be impacted.

Drawbacks

Iteratively checking heights could cause significant performance slow downs for large height ranges.

Alternatives

I could just iteratively call viewshed() at different observer heights.

Unresolved Questions

How results of the height analysis would be returned. One idea I had would be to return another DataArray where each point is the height at which the point is visible to the observer and NaN for invisible.

Additional Notes or Context

I am happy to develop this feature myself if it seems reasonable, I would definitely want a bit more guidance on implementation specifics.

@brendancol
Copy link
Contributor

@harrisonjkaplan Thanks for the write up and sounds like a cool use case!

Just to make sure I understand what you are looking for here:

For a given observer location, I would like to know at what height a given observable point is visible.

For a given observer location, I would like to know the minimum observer_elev (height) a given point is visible.

Is that correct?

Thanks again for the write up and sorry for delay in responding.

@harrisonjkaplan
Copy link
Author

harrisonjkaplan commented Sep 14, 2024

Hey @brendancol,

That is correct! I'm thinking it would return a DataArray where each value is the height at which the point is visible or -1 for invisible points. Do you have any suggestions for the implementation?

Thanks!

@brendancol
Copy link
Contributor

brendancol commented Sep 15, 2024

@harrisonjkaplan how about adding a new function to /experimental called something like min_observable_elevation with a signature like:

def min_observable_elevation(raster: xr.DataArray,
                             x: Union[int, float], 
                             y: Union[int, float],
                             target_elev: float) -> xr.DataArray

you can use as much of viewshed as you want, and make the api specific to that use case.

@harrisonjkaplan
Copy link
Author

Would you prefer a specific api for this use case? I was thinking that this could just be another parameter on the existing api.

@harrisonjkaplan
Copy link
Author

Also I am getting differences in viewshed() calculations between the GPU and CPU methods. With this script:

terrain = xr.DataArray(
        np.zeros((size, size)),
        dims=["y", "x"],
        coords={
            "x": np.linspace(0, size - 1, size),
            "y": np.linspace(0, size - 1, size),
        },
    )
terrain = generate_terrain(terrain)
center_x = terrain.coords["x"].values[size // 2]
center_y = terrain.coords["y"].values[size // 2]

vs_cpu = viewshed(terrain, center_x, center_y, 1)

terrain.data = cupy.asarray(terrain.data)
vs_gpu = viewshed(terrain, center_x, center_y, 1)

count_invisible_cpu = np.sum(vs_cpu.values == -1)

vs_gpu_converted = xr.DataArray(vs_gpu.data.get())
count_invisible_gpu = np.sum(vs_gpu_converted.values == -1)

logger.info(f"CPU count: {count_invisible_cpu} GPU count: {count_invisible_gpu}")

Where size is a user input. Is this a known difference?

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

2 participants