title: RFC7: Data validation for transactions

RFC7: Data validation for transactions

  • date: 2026-08-05
  • author: Tom Kralidis
  • contact: tomkralidis@gmail.com
  • status: draft
  • modified: 2026-08-05

Overview

This RFC describes the addition of data validation functionality in the context of OGC API transactional workflow.

Currently, pygeoapi allows for read/write capabilities for items based datasets. This is realized by:

  • using a data provider plugin with transaction capabilities
  • setting editable: true as part of the provider definition in configuration

pygeoapi data providers implement generic bindings to given backends and/or data formats. While pygeoapi's provider architecture enables a plugin developer to implement data validation internally, data providers typically implement read access and (optionally) transactional capability. Futhermore, depending on a given dataset, implementing business rules in a custom provider can lead to duplicated code for different dataset business rules. Finally, from a security perspective, data validation is a critical feature to be decoupled from pure transactional functionality, allowing for content validation and handling upstream of pure transaction workflow.

Proposed solution

pygeoapi will define a validator provider level configuration parameter that will allow a user to define a factory for data validation, in alignment and consistent with the plugin architecture.

Sample configuration:

lakes:
    type: collection
    title:
        en: Large Lakes
        fr: Grands Lacs
    description:
        en: lakes of the world, public domain
        fr: lacs du monde, domaine public
    ...
    providers:
        - type: feature
          name: Elasticsearch
          editable: true
          data: http://localhost:9200/ne_110m_populated_places_simple
          id_field: geonameid
          time_field: datetimefield
          validator:
              name: mycoolpackage.my_validator.MyCoolValidator

Implementation

  • for a given transactional workflow, pygeoapi will check if a collection's provider is editable (editable: true) and has a validator setting
  • if a validator is defined, pygeoapi will load the plugin and call its validate() method, throwing HTTP 400 if the plugin raises ValidatorValidationError
  • code will be implemented in pygeoapi/validator/base.py as an abstract base class with an validate(data, partials) -> None method
  • returns None on valid data payload
    • note that partials (default False) is added for HTTP PATCH workflow
  • raise ValidatorValidationError on invalid data payload
  • custom validator plugins are implemented by subclassing pygeoapi.validator.base.BaseValidator and overriding methods accordingly

The resulting implementation allows for loosely coupled data validation and transactional workflow, allowing for customized business rules against any data undergoing a transaction.

The initial implementation is focused on item types (features, records).

Backwards Compatibility Issues

Given this is a new feature, there are no backwards compatibility issues forseeen.

The new functionality will not be backported to other branches.

Testing

Tests will be added to ensure the expected functionality.

Documentation

Documentation will be added to the configuration and plugins sections.

Issue and Pull Request tracking

Pull Request: https://github.com/geopython/pygeoapi/pull/2396

Voting History

TBD