[wenzeslaus]

r.sim.water and r.sim.sediment silently take one degree as one meter in a latitude-longitude project, so the results there are meaningless. The cell size is converted to meters with the units-to-meters factor, but that factor is 1 in a latitude-longitude project, and the slope is computed from the cell size in project units anyway. A run in EPSG:4326 at 1 degree gives exactly the same output as a run in an XY project at 1 m, and there is no warning.

This makes both tools end with an error in a latitude-longitude project and ask the user to reproject the data to a projected coordinate system. Nothing changes in projected or XY projects.

Details (AI generated)

• Check: G_projection() == PROJECTION_LL right after G_parser() in both main.c files, before the seed, the region, or any input is read. The same check is in r.topidx, r.gwflow, and r.solute.transport.
• Message: Lat/Long project is not supported by r.sim.water. Please reproject the data to a projected coordinate system. The first sentence is the one from those three tools. Their second sentence, "Please reproject map first.", does not say what to reproject to, so the second sentence is new.
• Docs: one sentence in the description of each tool, next to the existing text on unit conversion, saying the tool requires a projected coordinate system and does not run in a latitude-longitude project. The .html files mirror the .md files.
• No output changes: the check only returns early in a latitude-longitude project. All existing r.sim.water and r.sim.sediment tests pass, including the gunittest suites in the nc_spm project.

Tests

• r_sim_water_latlong_test.py and r_sim_sediment_latlong_test.py (new, one test each, 0.2 s and 0.6 s):
  • Why: nothing tested the tools outside XY and projected projects, so the degree-as-meter behavior was not visible.
  • Checks: in an EPSG:4326 project with a 5x6 region, the tool fails and the error says that a Lat/Long project is not supported and that a projected coordinate system is needed.
  • Catches: the tools running in a latitude-longitude project. Both tests fail on main with "DID NOT RAISE" and pass with this change.
  • Placement: each tool has its own tests directory, so each test is next to its tool.
• Existing tests: 58 pytest tests in the r.sim.water and r.sim.sediment tests directories pass in 20 s. The r.sim.water gunittest suite (5 tests, 1 skipped) and the r.sim.sediment gunittest suite (1 test) pass in nc_spm_08_grass7.

Squash-merge commit message

Title:

r.sim: Refuse to run in latitude-longitude projects

Body:

r.sim.water and r.sim.sediment convert the cell size to meters with
G_database_units_to_meters_factor(), but the slope is computed from the
cell size in project units. In a latitude-longitude project the factor
is 1, so one degree was taken as one meter without any warning, and the
results were meaningless. A run in EPSG:4326 at 1 degree resolution gave
the same output as a run in an XY project at 1 m.

Both tools now end with an error in a latitude-longitude project right
after parsing, before reading any input, and ask the user to reproject
the data to a projected coordinate system. The error message follows
the one used by r.topidx, r.gwflow, and r.solute.transport. The
documentation of both tools states the requirement.

There are no output changes in projected or XY projects.

Written with the help of Claude Code.

The analysis, code and tests were done with Claude Code (Opus) and reviewed by me.