Search config option 1 with custom layer projection

[MattiasSp]

Fixes #1534.

Lets the getFeature function return features in the map's projection also when the layer projection differs.

Also a step towards #1139 as getFeature called for QGIS Server layers will always need to handle differing projections (due to QGIS Server only serving GeoJSON in EPSG:4326).

[steff-o]

Sorry, I haven't tested it yet. I have no doubt it is working, but I think that this would probably be a great time to loose a couple of lines of code by using the WfsSource class instead of having double implementation.

Most of the functionality in getFeature() already exist in the WfsSource class, so a minor change to that class could expose a getFeature() method that does exactly the same thing. Basically the only thing that is needed is to move the line super.addFeatures(features); to the calling functions and create a getFeature() method that calls _loaderHelper() and of course make sure all the filter stuff gets handled correctly.

The original getFeature() function is only used by the search functionality, but as it is exposed through the api (At least the MultiSelect plugin uses it to my knowledge), we can not just ditch it, but it can be rewritten as wrapper to WfsSource.getFeature() and taking care of keeping the function prototype intact. The source argument would be obsolete, unless someone actually calls it with another argument than the map configuration source array, which I hold for highly unlikely as it assumes that the features are fetched from a map layer, not any arbitrary WFS endpoint.

[steff-o]

Tested but I'm confused. It solves just the exact problem when using a layer configured using a different projection than the map and querying using a FID like search does. But it does not work:

1. When the layer has another default projection than the map but it is not configured in origo. The WfsSource class handles this by always request the features in the map's projection unless the layer has specified its own projection. If the srsname parameter is omitted the server will respond in its native projection, which will be unknown to getFeature() as origo does not use getCapabilities to discover it.
2. When getFeature() is called with an extent. The requested extent is not transformed and no SRS for the bounding box is present in the request. The server will then interpret the bounding box in the layer's native projection. Configuring a projection on the layer does not help here.

Maybe its just me that is lazy and never configure projections for every layer and lets the server handle that, but I think the result is inconsistent. At least case 1 should work. Case 2 is probably another issue as search never calls using extent, but would be nice to have fixed as well.

[jokd]

@MattiasSp Any update on this issue?

[steff-o]

@MattiasSp Is this PR still relevant now that getFeature() has been completely rewritten? To my belief projections would work as expected in WfsSource when using search.

Please review this PR and update it if possible or remove it.

[MattiasSp]

@MattiasSp Is this PR still relevant now that getFeature() has been completely rewritten? To my belief projections would work as expected in WfsSource when using search.

Please review this PR and update it if possible or remove it.

Thanks @steff-o! I agree that this can be closed now - great job om rewriting the getFeature() 👏