FG Studio helps analysts turn a stream-study question into an explicit, reusable study definition and a documented terrain foundation. It is the developing R Shiny browser client for FluvialGeomorph, which uses remotely sensed terrain and shared R methods to characterize stream geometry.
The intended workflow connects Study Area, Stream and Reach definition with survey selection, terrain development, Level 1 analysis and reviewable reports. Today, the app supports study definition, source acquisition, Stream DEM assembly and map-based hydro modification. Maps, guided choices and saved evidence make those steps accessible while keeping consequential scientific decisions with the analyst.
| Your question | Start here |
|---|---|
| Why does this app exist, and how does it fit the project? | FG Studio in FluvialGeomorph |
| How do I define a study, obtain DEM tiles and record reference systems? | Working with a Study Area |
| How do I trace behavior, diagnose a defect or extend the app? | Application lifecycle, then the relevant developer article |
| How are we testing better human and agent context routing? | Code maps and dual-mode development |
| How do I launch an installed package from R? | fgstudio::run_app(data_dir = "path/to/studio-data") |
The analyst guide includes the development-workstation launch procedure and storage details. The site also provides R API reference for the app entry points.
FG Studio owns browser interaction, workflow state and local storage orchestration. fluvgeo owns reusable scientific methods, spatial validation and reporting. Developing QGIS tools use that same backend through a desktop interface. The established ArcGIS toolbox and ohwm2 workflows remain separate clients; FG Studio is an independent application and a working design path for the open-source new-project workflow.
FGDB defines governed identities, relationships and eventual enterprise persistence. The User Manual and Technical Manual provide project-wide procedures and methods. The project overview explains these relationships, the local GeoPackage/GeoTIFF direction, and why study definition matters even when a project does not use FGDB.
- Create and reopen a local Study Area; define its boundary, Streams and Reaches.
- Discover Survey Collections, record acquisition intent, select and download source DEM tiles, and inspect their metadata and terrain previews.
- Specify a planar horizontal analysis CRS and a separate vertical target, elevation units and optional epoch/model metadata.
- Configure Survey Events and cell sizes; assemble and reopen Stream DEM editions with same-CRS bilinear resampling and retained processing evidence.
- Inspect elevation/hillshade in Hydro Modify, draw and reopen cutlines, and save hydro-modified DEMs while preserving their source and method provenance.
- Retain saved revisions and source evidence as the study evolves.
The current release is a trusted, single-analyst local development preview. Synthetic stream extraction is the next selected feature. Datum-operation review and explicit selection are available, but execution of selected cross-CRS pipelines remains pending. Level 1 execution, report delivery and governed FGDB delivery are not yet exposed by this app. Saving a CRS specification does not transform elevations or establish data fitness.
This site serves analysts and maintainers. Its numbered developer articles explain events, state, backend calls, persistence, failures and tests. Compact agent routes and generated code maps point to the same source and contracts. Human developers must be able to maintain the application without an agent or conversation history.
FG Studio is also a bounded testbed for improving that navigation. The first paired pilot supported keeping concise routes and explanations, but did not establish a speed or context-consumption improvement. The methods article describes the evidence, limitations and how future comparisons should be judged. AI-assisted development does not make AI services a requirement for using the application.
Build the local pkgdown site with ./dev/scripts/build-docs.ps1, then open
docs/index.html. This builds documentation without publishing it or changing
saved studies. Repository contributors should also read AGENTS.md and
dev/goals/project-plan.md before changing a workflow.