OSGeo
LOS: Add support for reporting where the LOS query failed
Purpose
Design the support for LOS query where the caller wants to know where LOS was violated in raster coordinate space.
Original Request
> Run bresenham terrain checking from (x1, y1) to (x2, y2).
The callback is run at every point along the line, which should return True if the point is above terrain. Bresenham2D will return true if all points have LOS between the start and end.
Just wondering that if the DEM pixels between (x1,y1) and (x2,y2y) are tested in order, could it be possible to report the pixel that breaks the line-of-sight? I mean the location "o" in this illustration. Maybe that information could be useful sometimes.
(x1,y1)------------o (x2,y2)
Originally posted by @jratike80 in https://github.com/OSGeo/gdal/issues/9506#issuecomment-2008166314
API Change
I think API needs to change. Perhaps it should be broken before the release, otherwise a new function needs to be added.
Current
bool CPL_DLL GDALIsLineOfSightVisible(const GDALRasterBandH, const int xA,
const int yA, const double zA,
const int xB, const int yB,
const double zB,
CSLConstList papszOptions);
Proposed
bool CPL_DLL GDALIsLineOfSightVisible(const GDALRasterBandH, const int xA,
const int yA, const double zA,
const int xB, const int yB,
const double zB,
int* xTerrainIntersection, int* yTerrainIntersection,
CSLConstList papszOptions);
- Is there a better name than
Violation? That makes it sound bad. PerhapsyLosBreak - Because bresenham may flip the direction of the line, the same LOS query on a raster rotated 180 degrees would result in a different location on the raster. If anyone knows of existing tools that report LOS violations, and what sort of data is reported, that would be helpful to design this feature. Note the current implementation is greedy - ie - it returns false as soon as the first point is found along the sight line that's below terrain. A UI graph might need to query all spots along the line anyways.
Perhaps int* xTerrainIntersection, int *yTerrainIntersection (and in that x,y order for consistency). I believe it would be desirable if that was always the first point when going from A to B, for predictability of the result.
Just updated the above comment. I believe the LOS calculation will return the points closer B first if the line goes from right to left because of the way bresenham works.
If we always want the function to return the closest intersection to A, then I think I need to change the internal algorithm to rotate the raster.
It would be good to have this in place at the latest for mid-April to be ready for 3.9.0. At the very least, add the new parameters in the function signature, even if there is no implementation behind.
The parameters were added in the function signature in https://github.com/OSGeo/gdal/pull/9585. There's just the implementation missing
I have a super simple implementation I can push that will return a location where LOS is violated.