Enhance bbox requests without geometry property to consider all geometry properties (3.6)

[lgoltz]

Backport #1730

[copierrj]

The TMC discussed this PR and we have a few concerns:

This PR changes the behavior of deegree in a non-obvious (= to the user) way and we're not sure if that's appropriate (especially in case of the 3.5 backport) without proper documentation or even making the new behavior opt-in.

We also discussed the use of ST_Union in the PostGIS dialect and we are very concerned that the proposed solution results in unexpected performance regressions. Calculating ST_Union can be very expensive on large complex geometries. There are many ways to preventing the use of this (potentially) expensive union, such as using ST_Collect instead, rewrite the query generator to compute extents for every column first and aggregate them later, etc.

Another thing that came up during the discussion was what happens when someone is mixing different coordinate systems and/or geometry columns that can contain null values..

[lgoltz]

Force push was required to remove a commit from PR #1729 / #1731 from this PR!
The comment #1732 (comment) regarding ST_Union is relevant for #1729 / #1731.

[julianzz98]

The enhancement was successfully tested on a local infrastructure setup, using both a PostgreSQL and an Oracle database database.

The following requests now successfully deliver data:

EPSG:4258 (2D)

• http://localhost:8099/deegree-webservices/services/inspirewfs_Gebaeude_3D_LoD2?service=WFS&request=GetFeature&version=2.0.0&srsName=http://www.opengis.net/def/crs/EPSG/0/4258&typeNames=bu-core3d%3ABuilding&bbox=49.1,6.1,49.8,7.1,http://www.opengis.net/def/crs/EPSG/0/4258&namespaces=xmlns(bu-core3d,http%3A%2F%2Finspire.ec.europa.eu%2Fschemas%2Fbu-core3d%2F4.0)&count=10

EPSG:7423 (3D)

• ​http://localhost:8099/deegree-webservices/services/inspirewfs_Gebaeude_3D_LoD2?service=WFS&request=GetFeature&version=2.0.0&srsName=urn:ogc:def:crs:EPSG::7423&typeNames=bu-core3d%3ABuilding&bbox=49.1,6.1,0,49.8,7.1,1000,urn:ogc:def:crs:EPSG::7423&namespaces=xmlns(bu-core3d,http%3A%2F%2Finspire.ec.europa.eu%2Fschemas%2Fbu-core3d%2F4.0)&count=10

[dstenger]

We consider the approach that all geometries are used when no geometry property is defined by the request as more intuitive and user friendly.

Note: The OGC specifications seem not to be clear about this. E.g. the OGC OWS Common 1.1.0 spec (06-121r3) describes the use of Bounding Boxes in chap. 10.2.5 (which is referenced by OGC WFS 2.0 spec), where OGC API Features 1.0.1 spec (17-069r4) allows both behaviors (see Requirement 24 /req/core/fc-bbox-response section B).

These are our reasons:

• There is no way for users to find out which geometry property is used if multiple geometries are provided. E.g. the capabilities provide no information about prioritization of geometry properties. So, the users can only guess how the service behaves. Thus, it is more intuitive and user friendly to consider all geometry properties.
• INSPIRE schemas (e.g. Building 3D) define feature types with multiple geometries. As deegree claims to fully support INSPIRE, the handling of INSPIRE data shall be as hassle free as possible.

Note: This change of behavior will mainly effect GetFeature GET KVP requests as POST XML requests define the used properties. Thus, most requests will not be affected by this change.