Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Daskifying viewshed#710

Unanswered
yiftachn asked this question inQ&A
May 18, 2022· 1 comments· 2 replies
Discussion options

Hey,
I considered taking on myself Daskifying the viewshed computation.
I saw that the functions implemented Dask followed the schema of:
_func = partial(numpy_func,..)
data.map_overlap(_func).

Is it the whole deal im viewshed as well?
If so, why hasnt it been done already as it seems like 5 minutes work.
Thanks!

You must be logged in to vote

Replies: 1 comment 2 replies

Comment options

We can usemap_overlap with algorithms that can be run in parallel. Imagine dividing the input raster into many chunks and compute the output chunk by chunk independently. With the current cpu viewshed implementation, output value of a pixel in a chunk can be calculated based on the input and also the output of some pixels in some other chunks. To daskify viewshed withmap_overlap, we need to rethink the algorithm to make it parallelizable.

You must be logged in to vote
2 replies
@yiftachn
Comment options

Thanks! I'll try to look it over.
What is the algorithm current cpu_viewshed implements?

@thuydotm
Comment options

viewshed was originally ported from GRASS:
https://github.com/OSGeo/grass/blob/master/raster/r.viewshed/viewshed.cpp

You can find here some additional background on this function:
http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.76.4282&rep=rep1&type=pdf

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment
Category
Q&A
Labels
None yet
2 participants
@yiftachn@thuydotm

[8]ページ先頭

©2009-2025 Movatter.jp