Root concat

[azahnen]

Pull request checklist

• Added/updated unit tests
• Updated documentation
• All checks are passing

Changes introduced by this PR

Closes #1269.

Depends on interactive-instruments/xtraplatform-spatial#285

Todo

• docs

Example

administrativeunit:
  type: OBJECT
  concat:
  - sourcePath: "/o73005{sortKey=sch}"
    type: OBJECT
    properties:
      id:
        sourcePath: sch
        type: STRING
        role: ID
  - sourcePath: "/o73004{sortKey=sch}"
    type: OBJECT
    properties:
      id:
        sourcePath: sch
        type: STRING
        role: ID

[azahnen]

Deployment of preview was successful: https://interactive-instruments-ldproxy-pr-1270.surge.sh

[cportele]

I created a new type Aeronautic in the daraa configuration as a concat of AeronauticCrv and AeronauticSrf. I then accessed various resources of the API with the following observations:

• Accessing feature resources was successful in formats HTML, GeoJSON and JSON-FG.
• In FlatGeobuf (and other formats that require a fixed schema), features that do not fully fit in the schema of the first option result in errors. My guess is that these encodings must be disabled for collections that use a root concat type (unless the options have exactly the same schema).
• The schema resource of the collection only represents the first option.
• The list of queryables for the collection was empty although three queryables were defined in the service configuration.
• Using such a type in a tile provider failed with the following error when accessing a tile: "Filter is invalid. Unknown property: 0_geometry."
• The schema in the tileset metadata only represents the first option.

If there is a constraint that all concat options must always have exactly the same schema, some of these issues are no longer an issue, but in that case, this probably should be checked.

[azahnen]

@cportele
The issues should be fixed.
For feature formats I introduced supportsRootConcat, which is currently only set to true for JSON-based formats and HTML. It would most likely be enough to use the union of all properties for the other formats, but for now they are disabled with a warning.

[cportele]

@azahnen
There is still at least one issue with tiles. The tileset metadata states that all geometries are lines. This is incorrect as some features have polygons. This has the side-effect that the default wireframe style only shows the line string features, the polygon features are not rendered.

The cause is that geometry type / dimension is determined from the first primary geometry property. This was correct when there could only be one, but with concat there can now be multiple.

It is easy to fix in this case, but we probably need to review all cases where a similar schema constraint is assumed, which no longer applies. Should I work on this?

[azahnen]

@cportele
Maybe it would make sense to adjust the MappingOperationResolver so that the types of the primary geometries are already aligned when used by any downstream cases?
If all primary geometries have the same type, nothing would be changed, otherwise all geometries would get the type ANY.

[cportele]

@azahnen
We would loose information that might be relevant in other places (e.g., the returnables schema). And it is not only the geometry type of the primary geometry, similar issues may surface with other aspects, too (e.g., primary temporal information, id properties, etc.).

As long as the feature schema in the root concat case is an any-of of the concatenated parts, we can no longer assume that at most a single property has a certain characteristic.

[azahnen]

@cportele
True. I think then it is best if you work on this.

[cportele]

@azahnen
OK, will do.