service-fs is the foundational storage layer for the platform's GIS pipeline — a flat-file data lake that stores raw geospatial points ingested from open sources (OpenStreetMap, Overture Maps Foundation) in separate retail and civic landing zones, available immediately to every downstream service without an ETL step. Retail records — commercial operators, anchor stores, fuel outlets — and civic records — hospitals, universities, transport hubs — are kept in distinct subtrees so the filtering and clustering services can work on each domain independently.

Data Ingestion and Storage

The service maintains a unified filesystem structure with separate landing zones for retail and civic infrastructure data.

• Retail landing: raw commercial operator records ingested from open geospatial registries (OpenStreetMap, Overture Maps Foundation).
• Civic landing: raw civic and institutional facility records from the same open sources.

Architectural Role

As the stateful layer of the platform, service-fs is responsible for data persistence. It is designed to be independent of the analytical software — if the GIS orchestration layer is re-provisioned, the core data assets remain intact within this layer. The clean separation between data persistence and analytical logic is a core design invariant. This same separation principle extends to the WORM ledger used for institutional records; see FS architecture for the full four-layer design.

Unikernel Implementation

In production, service-fs is deployed as a low-overhead unikernel. It provides a restricted API for the service-business and service-places intelligence layers to read raw data and write back processed results, enforcing clean separation between storage and analysis concerns. The co-location methodology describes how the clustering output is used to generate tier rankings.

See also

• service-business-clustering
• service-places-filtering
• app-orchestration-gis
• PointSav Link Service — fleet adapter that makes os-* storage accessible across node boundaries