Problem
FWA stream geometries from fwapg include Z and M coordinates (node elevations and route measures). Most downstream consumers (flooded, sf/GEOS operations, leaflet, mapgl) choke on XYM/XYZM:
Error: GEOS does not support XYM or XYZM geometries; use st_zm() to drop M
Every script using fresh output has to call sf::st_zm(drop = TRUE) before doing anything spatial. This is error-prone and repetitive.
Proposed Solution
Add a drop_zm parameter (default TRUE) to frs_db_query() or the individual fetch/network functions. When TRUE, apply sf::st_zm(drop = TRUE) before returning. When FALSE, preserve the Z/M values for workflows that need them (gradient calculations, 3D visualization, linear referencing).
The Z values are real node elevations — worth keeping as an option. But the safe default should be 2D geometry since that's what GEOS, flooded, and most R spatial operations expect.
Problem
FWA stream geometries from fwapg include Z and M coordinates (node elevations and route measures). Most downstream consumers (flooded, sf/GEOS operations, leaflet, mapgl) choke on XYM/XYZM:
Every script using fresh output has to call
sf::st_zm(drop = TRUE)before doing anything spatial. This is error-prone and repetitive.Proposed Solution
Add a
drop_zmparameter (defaultTRUE) tofrs_db_query()or the individual fetch/network functions. WhenTRUE, applysf::st_zm(drop = TRUE)before returning. WhenFALSE, preserve the Z/M values for workflows that need them (gradient calculations, 3D visualization, linear referencing).The Z values are real node elevations — worth keeping as an option. But the safe default should be 2D geometry since that's what GEOS, flooded, and most R spatial operations expect.