But it's computationally extremely difficult, as you say.
There's so much cheap GPU compute used for mining shitcoins and training glorified Markov chains on Reddit dumps, surely someone could spare a few racks to run some CFD on a detailed GIS model of our planet, to create lookup tables that would allow everyone to cheaply simulate all kinds of fun events, such as nuclear detonations, asteroid impacts, "rods of god", relativistic kill vehicles, supervolcano eruptions, etc. anywhere on the planet, at the push of a button.
The social value of this would be immense - even if you and me never used those precomputed LUTs for anything, they would surely help Randall Munroe or Kurzgesagt or others answer even more high-energy "what-if" questions with even greater accuracy!
Nobody ever did a sequel to
https://en.wikipedia.org/wiki/SimEarth
?
- Choose a grid of square cells of appropriate size (can be quite large here)
- Put it on a plane tangential to an idealized flat earth ground at the center (easy in ECEF)
- Offset by the desired height
- Perform a "raycast" from the center cell to the center of each other cell
- Calculate elevation from interpolated SRTM data along the way and store the maximum elevation* along the path (idea: something similar to DDA traversal through the SRTM data? Wouldn't be exactly linear, though…)
- You can pretty much derive anything via linear algebra from there
* "Elevation" from the viewpoint of the chosen plane, obviously.Almost any GIS software package can do it for you.
https://en.m.wikipedia.org/wiki/Viewshed
What you're suggesting is that, except you didn't account for curvature of earth.
That's likely where our different assesments come from, then. I was thinking more along the lines of "it's parallalelizable and easily offloaded to the client".
An addendum for completeness' sake, though :)
> What you're suggesting is that
Not entirely. I'd build a LUT of "how high up must you be to be visible here" per "pixel", instead of "is the ground here visible", which I'd argue is more useful for modelling here.
> except you didn't account for curvature of earth
I didn't spell it out explicitly, but that's not the case if you do your projections right. (And you have to project, as SRTM data is always relative to the EGM96 geoid.)