Improve extent handling for types, tilesets and collections

[cportele]

By default, spatial and temporal extents are automatically derived from the data for feature types / collections and tilesets.

The option defaultExtent allows to disable computing the extent and instead use a fixed value. There are two requirements that are supported by this:

1. Some API authors want to explicitly specify the extent for all collections of an API. This determines the value of extent in the collection resource and is independent of the data. A typical use case is the use of the bounding box of an administrative area or a fixed time period covered by a dataset, independent of the actual data, which may cover only a smaller extent.
2. The computation of the extent at startup can take some time for larger datasets. It should be possible to suppress the computation for performance reasons. This setting requires, that the extent is specified explicitly.

While these requirements are currently supported by the defaultExtent option, there are issues in the current implementation that should be improved.

One inconsistency is that the tile provider - unlike the feature provider - always computes the extent, even if spatialComputed: false is set.

Another difference between feature and tile resources is that the extent for features is only a metadata in the landing page and collection resources and has no further effect on the behavior of the API, whereas for tiles the tileset limits are determined from the extent in the API (but not the bounding box specification in the tileset, which is currently always the computed extent).

As the extent is computed by the providers, the configuration options should be specified there, too, and not only at the API level.

• Feature provider
  • Add configuration options extent.spatial and extent.temporal, also for the types. If set, the extent is never computed, the value is always used. The value for a type overrides a global value in the provider.
• Tile provider Features
  • Add configuration option extent.spatial for tilesetDefaults and tilesets. If set, the extent is never computed, the value is always used. The default is always the extent in the feature provider (explicitly set or computed).
• Tile provider HTTP
  • Add configuration option extent.spatial for tilesetDefaults and tilesets. If set, then the extent is used, otherwise determined from the extent of the tile matrix set.
• Tile provider MBTiles
  • Add configuration option extent.spatial for tilesets. If set, then the extent is used, otherwise determined from bounds in the metadata table, if set.

At the API level, defaultExtent should be deprecated.

Instead, we would should add extent to the building blocks FEATURES_CORE and TILES. The default would be the information from the respective provider, or the information from defaultExtent, if set.

Additional improvements:

• As with tiles, features should be selected taking an explicitly configured extent into account. This means that for all feature queries, explicitly configured extents would be taken into account during query generation.
  • There should be an option to disable this behavior.
  • Strictly, the additional predicate should use S_CONTAINS/T_CONTAINS to ensure that all selected features are within the extent. However, in order to keep the content consistent between features and tiles, S_INTERSECTS/T_INTERSECTS should be used instead, even if individual features can go beyond the extent.
• If the extent is configured to a fixed value, the extent should not be changed by new/modified features, as is currently the case.
• In the case of computed extents, the extents in the tilesets must also be adjusted when changes are made.