gpf-schema-store

Work in progress (see ROADMAP)

Non official / experimental implementation of OGC API Features - schema by enriching information from the Geoplateforme WFS to ease data discovery by AI (and humans).

Data model

The internal enriched collection model is :

• id : WFS GetCap FeatureType <Name> (namespace:name = unique identifier)
• namespace : namespace identifier (e.g BDTOPO_V3)
• name : name identifier (e.g batiment)
• title : WFS GetCap <Title> "BDTOPO : Bâtiments"
• description : WFS GetCap <Abstract>
• x-ign-theme, x-ign-selectionCriteria, x-ign-representedFeatures : optional IGN enrichment metadata
• required : optional list of required property names
• properties : Array of property defined by name, type, title and description. oneOf is available for rich enumerated values.

When merged with data/overwrites, WFS identifiers and property types are kept from data/wfs, while overwrite metadata is taken from overwrites when available.

The public catalog output is a logical JSON Schema compatible with OGC API Features schemas. It is not a dump of the internal model.

Overwrite format

Overwrite files live in data/overwrites/{namespace}/{name}.json. The current format does not contain root id, namespace, or name; those values are derived from the WFS snapshot and file path.

{
  "title": "Point de repère",
  "x-ign-theme": "Transport",
  "description": "Point créé par le gestionnaire du réseau routier...",
  "x-ign-selectionCriteria": "Les objets Point de repère retenus sont...",
  "x-ign-representedFeatures": ["Point de repère routier"],
  "properties": [
    {
      "name": "cote",
      "type": "string",
      "title": "Côté",
      "description": "Côté de la route...",
      "oneOf": [
        {
          "const": "D",
          "title": "D",
          "description": "Chaussée droite."
        }
      ]
    }
  ],
  "required": ["cleabs", "geometrie"]
}

The overwrite type field is accepted as overwrite input only. The merged catalog always keeps the WFS property type.

Usage

WARNING: The MCP ignfab/geocontext relies on a published version. The following instructions are related to the maintenance of the schema.

Build

npm install
npm run build

Test

# To run unit test only :
npm run test

# To compute coverage :
npm run test:coverage

# To run integration test on https://data.geopf.fr/wfs
npm run test:all

Configure filtering

Edit data/namespace-filters.yaml to decide which namespaces are kept or ignored and to assign metadata (product, ignoredReason) using first-match-wins rules.

Generate namespace report

Update data/namespaces.csv to review every discovered namespace, its computed metadata (product, ignored, ignoredReason), and its collections :

npx gpf-schema-store update-namespaces

Fetch schema from GPF WFS

Fetch WFS schemas from GPF, apply the namespace filtering rules defined in data/namespace-filters.yaml, and regenerate data/wfs directory :

# download data/wfs/{namespace}/{name}.json
npx gpf-schema-store update

Check local overwrites

Compare local WFS snapshots stored in data/wfs with local overwrite files in data/overwrites.

# check that overwrites are aligned with local snapshots in data/wfs
npx gpf-schema-store check-overwrites

Test local search

Use the search command to quickly inspect the results returned by the search engine with its default options.

# display the top 5 results
npx gpf-schema-store search chef lieu commune --limit 5

# another example
npx gpf-schema-store search bdtopo batiment --limit 3

The output shows the collection identifier, the computed score, and MiniSearch match details, which makes it easier to compare ranking behavior before and after a search change.

Render collection schema files

Write the public catalog JSON Schema files after applying data/overwrites, to an output directory.

# write collection schemas to ./tmp/catalog/{namespace}/{name}.json
npx gpf-schema-store render-catalog ./tmp/catalog

# start from a clean output directory
npx gpf-schema-store render-catalog ./tmp/catalog --clean

Each rendered file is a JSON Schema 2020-12 object with x-collection-id, type, title, description, properties, and required. Geometry properties are represented with format: "geometry-{type}" and x-ogc-role: "primary-geometry". The BDTOPO identifier property cleabs is annotated with x-ogc-role: "id".

Test a local package build in geocontext

If you want to test a local change from this package inside geocontext, the simplest and most reliable workflow is to install a local tarball generated with npm pack.

This is the recommended approach because it is very close to a real npm publish:

• it uses the package files / exports configuration
• it only installs what would actually be shipped
• it avoids some of the resolution quirks of npm link

From this repository:

npm run build
npm pack

This creates a tarball such as ignfab-gpf-schema-store-0.1.0.tgz.

Then, from your local geocontext checkout:

cd /path/to/geocontext
npm install /path/to/gpf-schema-store/ignfab-gpf-schema-store-0.1.0.tgz
npm run build
npm test

When you make a new change in gpf-schema-store, rebuild and regenerate the tarball, then reinstall it in geocontext.

If you only want to test locally without updating package.json, use --no-save:

npm install --no-save /path/to/gpf-schema-store/ignfab-gpf-schema-store-0.1.0.tgz

If you already installed the local tarball with a saved dependency, restore the published dependency afterwards:

npm install @ignfab/gpf-schema-store@^0.1.0

Using a direct local path like npm install ../gpf-schema-store can work too, but it is less predictable because it depends on the local package state and requires extra care to keep dist/ up to date.

License

MIT