#GSX tools

The GSX tools bring conservation, biodiversity, environmental and industry analysis (surveying, energy, oil and gas, mining, forestry, maritime, aeronautical, transport, urban, rural, assets and ENSO) into GeoSpaX 3. They are 22 default plugins, one per domain, each with its tools:

They ship with GeoSpaX and are in the Explorer under Plugins (one per domain), in the Tools tab under Plugins › and in the plugin manager marked default plugin. They are not on the Analysis, Imagery or Modelling tabs, which hold GeoSpaX's own tools. All 22 run the same code, the shared GSX library in plugins/gsx (library: true: not listed, but recipes, the API and MCP call its tools as gsx/<tool>, so a tool gives the same answer from every domain).

A tool's dialog opens with its inputs already chosen, as in ArcGIS Pro's geoprocessing pane:

• Layers: the layer selected in Contents when it fits, unless another layer fits the input better by name (a habitat layer for "Habitat", a layer with a species column for diversity). Points, lines and polygons go only to inputs that take them; a second input (B, protected areas) gets a different layer, and the second date of a pair the layer's later version (habitat → habitat_2024).
• Fields: a field of the right type from that layer, its name matching the input's (dist_to_road_km for "Distance field", species for "Species"); identifiers such as site are never taken as values. Optional inputs (a constraint field, a second layer) stay empty unless their own name names the field, since a wrong constraint would change the result.
• Rasters: a multiband image for "Image", a raster named as a DEM for "Elevation" (never a temperature or other surface), the earlier and later of two dated rasters for change, and the climate rasters as species-model covariates.
• Never earlier results, unless you select one: a tool starts from your data. When nothing fits, the input stays empty and the tool says what it needs ("Choose a DEM").

The analysis code (plugins/gsx/src/analysis, about 5,000 lines of TypeScript on Turf and proj4) is @geospax/analysis, unchanged, so its golden-value tests run as they did (103 of them, in CI). It needs Node.js 18+ and nothing else; no tool here goes online.

#The tools (phase A)

Every tool shows its results in its dialog (a table, plus the method's caveats) and adds its layers to the map, styled by AutoMap. Areas are in hectares and equal-area (an auto-centred Lambert azimuthal projection) unless you choose spherical. Each result layer records the tool, its parameters and the 2.0 provenance stamp.

Layers in any format work: the plugin asks for GeoJSON (geojson: true in its plugin.yaml), so GeoSpaX hands it each layer the tool uses as GeoJSON, whatever the source (GeoPackage, Shapefile, FlatGeobuf …).

#Rasters and species distribution (phase B)

The rasters come from the map (Explorer › Online data › Climate gives WorldClim or CHELSA; › Elevation the Copernicus DEM; Imagery the latest Sentinel-2 bands), and results go back to the map styled for what they are: suitability on a fixed 0–1 Viridis scale, change on a diverging red–blue scale centred on zero, classes with their own colours. Several environmental rasters are resampled onto the first one's grid.

Cross-validation. Points are grouped in square lon/lat blocks (automatic size: about a sixth of the study area; or set it). Blocks that hold presences are dealt to the folds first, so every held-out fold has presences even when occurrences are clustered; when there are fewer such blocks than folds, the number of folds drops to match and the result says so. Report the cross-validated scores: training AUC is optimistic, and suitability from presence-background data is relative, not a probability of presence.

Checked against synthetic data with known answers (tests/rastertools.test.ts): an image whose west half is vegetated (NDVI extent 50.0 %), a planted loss strip (found cell for cell), a 10° ramp (mean slope 10° ± 0.2) and a species confined to one climate corner (cross-validated AUC above 0.85 for Mahalanobis and logistic, above 0.7 for BIOCLIM).

#From earlier GeoSpaX (phase C)

Tool results can now carry charts (figures in the plugin answer, drawn as images so a plugin's SVG cannot run scripts). Checked (tests/legacytools.test.ts): a two-block pattern is strongly clustered with high-high and low-low on the right sides and no outliers; a checkerboard with rook neighbours gives Moran's I = −1 exactly; the global I equals the textbook double sum; a north-facing ramp DEM gives the profile length (11.1 km for 0.1° of latitude) and climb (1,000 m) it should. On the sample transects, species richness gives I = 0.82 with 8 neighbours (the earlier guide expects about 0.8).

Sample data (Explorer › Sample data) brings back the Papua New Guinea set: the survey transects, birdwing butterflies and their host vines, forest patches, a habitat grid, streams, WorldClim temperature and rainfall and tree cover (samples/png/README.md). 1.4.2 .gspx and 2.0 .geolibre.json projects open like any file: their embedded layers come onto the map (styles and layers that only point at outside files are not carried over).

#From scripts

curl -X POST localhost:8080/api/plugins/gsx/tools/fragmentation/run \
  -d '{"params": {"patches": "forest.gpkg", "edge_m": 100}}'

scripts/test-gsx.mjs runs every tool this way. Recipe steps that call plugin tools (so the domain kits can chain them) come with the domain kits.

#Building the plugin

plugins/gsx ships its built file (run.mjs) so it runs without a build step. To change it:

cd plugins/gsx
npm ci
npm test            # the analysis tests
npm run build       # src/ → run.mjs
node gen-manifest.mjs   # src/tools.ts → plugin.yaml

CI checks that run.mjs and plugin.yaml match the source.

#Domain kits

Ready-made recipes that chain online data, the tools above, a finished map and a report. They are in Analysis › Recipes (grouped by domain), the Toolbox under Ready-made analyses, and Lazy mode's Find patterns; each takes a few inputs and runs to the end by itself.

Every kit is an ordinary recipe (recipes/kit-*.yaml): open it in the Automate pane to see each step, change a default, or save a copy with your own steps. Kits call the tools with the tool step (AUTOMATION §2).

Checked: scripts/test-kits.py runs all nine against data with known answers (scripts/test-kits-data.R): 25 % protected, 12 patches, net land-cover change of zero, 12 species in 3 clusters, the planted vegetation-loss strip, and a future range that is both lost and gained. Kits that download data run with the downloads swapped for local test rasters, so their tools, maps and reports run for real; the downloads need internet and are covered by the data.fetch tests. The 12 industry and El Niño kits run the same way in scripts/test-domain-plugins.py.

Limits of the industry tools: the ENSO indices and DEMs download from the internet unless you give an offline file or a mirror; AGD66 to GDA94 uses a 7-parameter shift (about 1 m), not NTv2 grids; the obstacle limitation surfaces cover non-instrument runways only; LiDAR clearance assumes one conductor height; least-cost routes follow cell centres; date-typed fields in a layer are dropped, so give expiry and inspection dates as text (1 Jan 2026) and AIS times as epoch seconds.

#Online data from the 2.0 catalogue

earlier GeoSpaX listed these sources; 3.0 fetches them, for the area on the map, with their citations (Explorer › Online data, and its Check species names; steps in AUTOMATION.md):

Not yet: coral reef extent, mangroves and the SPREP Pacific layers. The SPREP Inform portal refuses automated requests (a Cloudflare browser challenge), so it needs another route.

#Coming next

• More kits: marine (OBIS with ocean covariates), hydrology (watersheds and stream networks with the raster tools), ecosystem services.

#Credits

The GSX analysis and its tests: in4metrix, MIT. Turf (MIT) and proj4js (MIT) are bundled into run.mjs.