Fixed empty GFI response on a FeatureType with multiple geometry columns

[lgoltz]

Currently a GetFetureInfo requests based on FeatureLayer uses the first geometry column, to match the requested click point. This geometry may differ from the geometry used to render the GetMap request or may be empty,

This PR fixes this by using the same geometry property for GetFeatureInfo requests from the style as the GetMap request.

Fixes #1640.

[julianzz98]

The fix was successfully tested on a local environment!

[tfr42]

@julianzz98 How does the GFI request/response changes when the tunable deegree.sqldialect.consider-all-geometry-columns is enabled or not?

[stephanr]

We discussed this PR in yesterday's TMC meeting, and from the currently supplied information in this PR, the following questions arose:

• It looks like this PR will change the behavior of deegree, which currently would be included in an incremental update that may or may not surprise users.
• This PR shares similarities with Enhanced bbox requests without geometry property to consider all geometry properties (3.6) #1732 where, after discussions about the behavior change, it was changed to be opt-in via tunable. And visually it is unclear if and how both PR are related to each other.
• Does the change in by including more geometry properties have a security implication by widening the scope for the query to the datastore?

To go into detail about the security implications here, as discussed in the TMC meeting, it is unclear if the additional filter will widen or narrow the feature requested from the feature store (are more features returned, or are only the same features returned and correctly selected for rendering)?.

With the current supplied information, this question could not be answered.

So in my understanding, a WMS GetFeatureInfo should request the same features as a WMS GetMap would do and then filter out the features requested by the GetFeatureInfo click position.

So one way to better understand the implications of this PR would be to document the SQL before and after applying this PR to see if there are security implications. (Maybe also with and without the tunable of #1732, if this changes the behavior.)

[lgoltz]

SQL of a GetMap request (no changes with this PR):

SELECT X2.attr_gml_id,
...
FROM mfu.us_govserv_governmentalservice X2
WHERE (X2.us_govserv_servicelocation_us_govserv_servicelocationtype_u_450 && ST_SetSRID(ST_GeomFromWKB(?), 4258)
       AND X2.us_govserv_servicetype_href = ?) FETCH NEXT 10000 ROWS ONLY

SQL of a GetFeatureInfo request, before the fix:

SELECT X2.attr_gml_id,
...
FROM mfu.us_govserv_governmentalservice X2
WHERE (((X2.us_govserv_areaofresponsibility_us_govserv_areaofresponsibil_81 && ST_SetSRID(ST_GeomFromWKB(?), 4258)
         AND ST_Intersects(X2.us_govserv_areaofresponsibility_us_govserv_areaofresponsibil_81, ST_SetSRID(ST_GeomFromWKB(?), 4258)))
        AND X2.us_govserv_servicetype_href = ?)
       AND ST_Intersects(X2.us_govserv_areaofresponsibility_us_govserv_areaofresponsibil_81, ST_SetSRID(ST_GeomFromWKB(?), 4258))) FETCH NEXT 100 ROWS ONLY

SQL of a GetFeatureInfo request, after the fix:

SELECT X2.attr_gml_id,
       X2.gml_identifier,
       X2.gml_identifier_attr_codespace,
       X2.us_govserv_areaofresponsibility_attr_nilreason,
       X2.us_govserv_areaofresponsibility_attr_xsi_nil,
...
FROM mfu.us_govserv_governmentalservice X2
WHERE (((X2.us_govserv_servicelocation_us_govserv_servicelocationtype_u_450 && ST_SetSRID(ST_GeomFromWKB(?), 4258)
         AND ST_Intersects(X2.us_govserv_servicelocation_us_govserv_servicelocationtype_u_450, ST_SetSRID(ST_GeomFromWKB(?), 4258)))
        AND X2.us_govserv_servicetype_href = ?)
       AND ST_Intersects(X2.us_govserv_servicelocation_us_govserv_servicelocationtype_u_450, ST_SetSRID(ST_GeomFromWKB(?), 4258))) FETCH

The main difference is the geometry column used in the WHERE clause. Before it was the first in the SQLFeatureStore (us_govserv_areaofresponsibility_us_govserv_areaofresponsibil_81), after the fix the same geometry column as for the GetMap request is used for filtering. For both, GetMap and GetFeatureInfo, the geometry column derived from the style definition is used (new line in FeatureLayer.java).

IMHO we can label this PR as a bug fix. Now the same geometry column is used for the GetFeatureInfo request as for the GetMap request. Before it could happen, that the GetFeatureInfo response contained features not shown in the click position of the map.

As the geometry column is already selected before the SQL is created, the PR #1732 does not apply. This could be the case only if there is no style definition for the requested layer. We did not test this scenario with #1732. I propose to create a new ticket to test the tunable deegree.sqldialect.consider-all-geometry-columns for WMS Get Map and GetFeature requests with a simple WMS layer without style.

[tfr42]

Thank you for your contribution. Your pull requests has been accepted by the TMC. Please find more information in the meeting chat available at https://github.com/deegree/deegree3/wiki/tmc-meeting-minutes-20260128.
This pull request will be part of the 3.6.6 release.

@tfr42 A note shall be added to the release notes.