AdminConsole
Tutorials/Advanced
Advanced2 hrREST + Web

Build a reproducible site-selection model

Publish layers, generate catchments, join signals, score candidates, and share results.

By the endA governed retail expansion analysis.
Real-world scenario

Build against an explicit contract

A retailer must compare candidate sites using a reproducible model that another analyst can rerun and challenge.

A Mappls developer projectA restricted REST applicationFixture data with no production credentialsA request, aggregate, or correlation ID strategy
Step 1

Define the user and system contract

A retailer must compare candidate sites using a reproducible model that another analyst can rerun and challenge. Record the region, data freshness, latency budget, privacy purpose, credential owner, and fallback before choosing an SDK or endpoint.

Step 2

Version every input

Record immutable dataset versions, content hashes, CRS, schema, source, license, and observation date before analysis.

GIS & Analytics · SDK or product slice
import requests

response = requests.post(
    f"{MAPPLS_GIS_BASE_URL}/analysis/point-in-polygon",
    headers={"Authorization": f"Bearer {token}"},
    json={
        "pointsDatasetId": "deliveries_2026_08",
        "polygonDatasetId": "service_zones_v4",
        "include": ["zone_id", "manager", "sla_minutes"],
    },
    timeout=30,
)
response.raise_for_status()
job = response.json()  # Poll or subscribe to the returned analysis job.
Step 3

Make scoring deterministic

Persist catchment parameters, joined signal versions, normalization, weights, exclusions, and tie-breaking with each attempt.

Step 4

Govern sharing

Publish a result revision with lineage, audience, expiry, export/embed policy, and revoke access without rewriting the decision record.

Step 5

Prove the production behavior

Automate the happy path and every named failure. The release is ready only when the same inputs and parameters reproduce the score; invalid crs fails with actionable diagnostics; a shared result resolves to immutable lineage. Capture provider request identity without logging credentials or unnecessary precise location.

Recovery design

Failure modes you must exercise

source schema or CRS drift

Fail fast with a typed, user-safe outcome and preserve the original request identity.

processing fails after partial compute

Keep the last verified state, mark freshness honestly, and retry only within the documented idempotency boundary.

expired or revoked share is requested

Reconcile durable local and provider evidence before declaring success or issuing a compensating command.

Never turn uncertainty into success

Timeout after a stateful command is an unknown outcome. Query by provider/idempotency identity or wait for authoritative events; do not blindly retry a new command.

Acceptance criteria

Definition of done

the same inputs and parameters reproduce the scoreinvalid CRS fails with actionable diagnosticsa shared result resolves to immutable lineage

REST production checks

Credentials never reach a browser or mobile bundleTimeout, retry, and idempotency policies are explicitCoordinates, addresses, and identifiers have data-retention rulesEvery operation is attributable in logs and usage reporting
Grounded implementation

Continue from source, contracts, and a full app

These links resolve to repository-derived evidence; unsupported package names and endpoints are not filled in from guesswork.

Study the complete Governed spatial analysis state machine
Tutorial complete

Run it, break it, then observe it

Start with fixture credentials, execute the failure plan, and use request logs, usage, webhook evidence, and operational metrics before promoting traffic.