Skip to content

ldproxy extent handling - #511

Open
PZahnen wants to merge 20 commits into
masterfrom
ldp-94-ldproxy-extent-handling
Open

PZahnen wants to merge 20 commits into
masterfrom
ldp-94-ldproxy-extent-handling

Conversation

@PZahnen

@PZahnen PZahnen commented May 21, 2026 •

Copy link
Copy Markdown
Contributor

Implements the xtraplatform-spatial part of ldproxy/ldproxy#1171: spatial and temporal extents can be configured in the providers instead of only at the API level.

Configuration

Feature providers

  • extent.spatial and extent.temporal on the provider and on each type. A configured extent is never computed. Each part of a type extent replaces the same part of the provider extent.
  • Spatial coordinates are in the native CRS of the provider. Temporal bounds are dates (yyyy-MM-dd, UTC, end inclusive) or date-times with offset; a missing bound is open.
  • computed: true on a type discards an inherited fixed extent. computed: false is rejected, and computed must not be combined with coordinates or bounds.

Tile providers (tilesetDefaults and tilesets, coordinates always in CRS84)

  • Features: if not set, the extent of the feature provider (fixed or computed) is used, as before.
  • HTTP: if not set, the union of the extents of the tile matrix sets is used.
  • MBTiles: if not set, bounds from the MBTiles metadata is used.

Query restriction (SQL providers only, queryGeneration)

  • restrictToSpatialExtent and restrictToTemporalExtent (both default true) add S_INTERSECTS/T_INTERSECTS predicates for fixed extents to all queries for multiple features. Queries for a single feature by id are not restricted.

Behavior changes

  • Fixed extents are returned before the stats cache, so feature changes no longer affect them. Computed extents, including tileset bounds, are still recomputed on changes.
  • WFS and GraphQL providers: an inverted containsKey check made getSpatialExtent (and getFeatureCount for GraphQL) always return nothing; they now return computed values.

Notes

  • FeatureTypeConfiguration.getExtent() conflicts with getExtent() in ldproxy's FeatureTypeConfigurationOgcApi; this is resolved in the related ldproxy PR.
  • All new options are @since v4.9.
  • Tests: SpatialExtentSpec, TemporalExtentSpec, FeatureTypeExtentSpec, ExtentFiltersSpec, TileProviderHttpExtentSpec and extent cases in FilterEncoderSqlSpec (SQL text for PostGIS only).

@PZahnen
PZahnen requested a review from azahnen May 21, 2026 16:54
@PZahnen PZahnen mentioned this pull request May 21, 2026
3 tasks done

@azahnen azahnen left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

  • TemporalExtent
    • should be UTC ISO datetime (YYYY-MM-DDTHH:mm:ss.sssZ)
    • use DateTimeFormatter.ISO_INSTANT.parse to validate
    • add methods for start and end (@Value.Derived, @JsonIgnore) that return Instant (Instant.from(DateTimeFormatter.ISO_INSTANT.parse))
  • SpatialExtent
    • toBoundingBox should be moved here with nativeCrs as parameter
  • FeatureProvider*
    • it seems there is a lot of duplicated code, move to AbstractFeatureProvider where appropiate

@PZahnen

PZahnen commented May 22, 2026

Copy link
Copy Markdown
Contributor Author

Thanks, should be taken care of now.

@PZahnen
PZahnen requested a review from azahnen May 26, 2026 08:05
@azahnen
azahnen force-pushed the ldp-94-ldproxy-extent-handling branch 2 times, most recently from 5a42e4f to 219a7ce Compare October 31, 2026 18:52
@azahnen
azahnen force-pushed the ldp-94-ldproxy-extent-handling branch from 219a7ce to deab143 Compare October 31, 2026 19:20
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants