I studied the r.geomorphon module’s architecture and have added it to my proposal as a secondary priority target after r.proj.
What I learned:
The module classifies terrain into landforms using an 8-direction line-of-sight approach. For each cell, it walks outward along 8 cardinal/diagonal directions, computing zenith and nadir angles via atan2() to build a ternary pattern that maps to one of 10 landform types. The per-cell cost scales with the search parameter — with search=50 to search=500, this means hundreds to thousands of calculations per cell, making it a strong parallelization candidate.
Thread-safety findings:
The inner column loop follows the same independence pattern as r.param.scale. I identified two blockers:
search_distance and flat_distance are globals mutated in extended mode — solution is to refactor calc_pattern() to accept them as parameters
G_distance() is not thread-safe for lat/lon projections due to static mutable state in lib/gis/geodist.c
Question for mentors:
For the G_distance() issue, I see a few options:
Disable OpenMP for LL projections (simplest, but no speedup for LL users)
Pre-compute a distance lookup table before the parallel loop (distances repeat for same row offsets)
Address this at the library level (broader impact but likely out of scope)
Which approach would you recommend? I want to ensure the design aligns with GRASS conventions before writing code.
The updated proposal has been submitted with r.geomorphon planned for Weeks 6-8.
Hello Sir @hcho , I would really appreciate it if you could review my proposal when you have some time.
I’ve attached the drive link ,GSOC. The Google Doc may not appear as refined.
The PDF has already been submitted, but I would value any suggestions for improvement.
I think disabling it for LL is an okay solution, but to be honest, the other options would have to be evaluated first in terms of their advantages and disadvantages, so I can’t give you answer in a short time, that would be something to do as part of GSoC.
Thank you @annakrat , that’s helpful framing. I’ll treat the G_distance() thread-safety evaluation as part of the GSoC work itself rather than something to resolve pre-proposal. For now, I’ll note the LL projection limitation in the proposal with a fallback to serial execution, and plan the lookup-table approach as a stretch goal to investigate during the project.
We will get to it. It won’t hurt your application if it’s not merged. It’s larger change, so I need to take my time to check it. You have to understand, for the most part, maintainers do it on their volunteer time.