Clarify CRS handling and reprojection behaviour for PostGIS providers

[denizk99-ea]

We’re working with UK geospatial datasets stored in PostGIS using British National Grid (EPSG:27700) via pygeoapi (OGC API Features) and want to confirm best practice for CRS handling.

Our understanding is that pygeoapi does not automatically reproject PostGIS geometries, that declaring crs or storage_crs only advertises supported CRS to clients, and that CRS transformation is intentionally delegated to the backend. As a result, the recommended pattern appears to be exposing data through database views using ST_Transform(geom, 4326) and keeping the API default CRS as WGS84 for OGC compliance, allowing GIS clients to reproject back to BNG automatically.

We’d appreciate confirmation that this is the intended approach, clarification on whether storage_crs is expected to apply to SQL/PostGIS providers, and whether it would make sense to document this behaviour more explicitly, as it’s easy to assume CRS configuration alone will handle reprojection.

[webb-ben]

Hello @denizk99-ea

pygeoapi support CRS re-projection for all Feature providers. Some examples of how this behaves can be found in the documentation at https://docs.pygeoapi.io/en/latest/crs.html. This would be the place to add any missing documentation.

The brief summary is that a provider can be configured such that bbox coordinates are transformed to the source CRS and response features are in the requested CRS. This is done with the two configuration options you identified:

• storage_crs -> URL of the source data (for pygeoapi to use to transform bbox / CQL queries AND as the source for the pyproj CRS transform.
• crs -> List of supported input and output CRS uris. For OGC compliance this defaults to WGS84 if not provided.

From what you are describing it sounds like you want:

source_crs: https://www.opengis.net/def/crs/EPSG/0/27700
crs:
    - http://www.opengis.net/def/crs/OGC/1.3/CRS84
    - https://www.opengis.net/def/crs/EPSG/0/27700

This would allow pygeoapi to handle feature reprojection to WGS84 automatically, while users could append the query arg crs=https://www.opengis.net/def/crs/EPSG/0/27700 to return features as EPSG:27700. This would also allow input bbox queries to use any CRS declared in the crs list (should there be other supported CRS systems you wish to include).

[webb-ben]

As for the interactions specifically with the PostGIS provider, in #2010 and #2102 you will note there are some special caveats because PostGIS spatial_ref_sys table generally only includes EPSG codes. As such, features projected in OGC:CRS84 often live in a column incorrectly set to geometry with SRID 4326.

pygeoapi CRS re-projection respects axis ordering and thus distinguishes between http://www.opengis.net/def/crs/OGC/1.3/CRS84 and http://www.opengis.net/def/crs/EPSG/0/4326. Should you need both, they would both have to be included in the storage_crs / crs list respectively.