Hi @meyerlor

I did some quick tests, I tried to enable snapping on the following project:

repository=testsrepository&project=form_edition_value_relation_field

The snap is only on the list layer :

but the server returns an incorrect bbox/geometries for the list layer.

Project is in 3857, list layer is in 4326

Am I doing something wrong? Can you replicate the problem?

Thanks!

@mind84 you are right — none of the test projects use a datum-shifted CRS, so the e2e test checks only the protocol change (WFS 1.1.0 + SRSNAME) rather than the coordinate values directly. Adding a project with e.g. EPSG:28992 or EPSG:25832 (my usual one) would also require NTv2 grid files on the test QGIS Server. The test only proves the new code path is taken, which eliminates the client-side proj4js transform by construction — the coordinate accuracy guarantee comes from QGIS Server/PROJ once SRSNAME is present.

Hi @meyerlor,

I took a quick look, so please correct me if I'm wrong!

The main problem is that the WFS call is made to PostGIS for DB layers, see getFeaturePostgres method in WFSRequest.php class. The query that is made has a fixed CRS of 4326 for bboxes and geometries.

The following example shows the query generated with the new method:

WITH source AS (
         SELECT "id", "code", "label", "code_parent", "geom" AS "geosource" FROM "tests_projects"."form_edition_vr_list" WHERE True LIMIT 1000
        )
        --SELECT row_to_json(fc, True) AS geojson
        --FROM (
        --    SELECT
        --        'FeatureCollection' As type,
        --        array_to_json(array_agg(f)) As features
        SELECT row_to_json(f, True) AS geojson
            FROM (
                SELECT
                    'Feature' AS type,
         Concat(
            'list',
            '.',
            "id") AS id,
                        array_to_json(ARRAY[
                            ST_XMin(ST_Transform(ST_Envelope(lg.geosource::geometry), 4326)),
                            ST_YMin(ST_Transform(ST_Envelope(lg.geosource::geometry), 4326)),
                            ST_XMax(ST_Transform(ST_Envelope(lg.geosource::geometry), 4326)),
                            ST_YMax(ST_Transform(ST_Envelope(lg.geosource::geometry), 4326))
                        ]) As bbox,
            
                        ST_AsGeoJSON(ST_Transform(lg.geosource::geometry, 4326))::json As geometry,
            
                    row_to_json(
                        ( SELECT l FROM
                            (
                                SELECT "id", "code", "label", "code_parent"
                            ) As l
                        )
                    ) As properties
                FROM source As lg
            ) As f
        --) As fc

Geometries are always returned in 4326.

Also bbox is not considered, probably due to the BBOX sintax passed as param:

-899310.3675109865,5331047.836042481,1412145.3675109865,6412173.163957519,EPSG:3857

The CRS added as the fifth element seems to be a format not supported by QGIS Server (maybe is related to Geoserver?) -> EDIT: QGIS Server supports this format

Ignoring the BBOX causes all features to be requested, which can cause performance issues.

It would probably be necessary to modify this method to get a Postgis side conversion, or alternatively force the QGIS Server request with the WFS force_qgis parameter.

@rldhont @mdouchin what do you think?

Thanks!

Hi @mind84, good catch — you're right on both. Both issues are in the PostGres direct path (getfeaturePostgres), which is what gets hit for PG-backed layers:

1. BBOX ignored: getBboxSql rejects anything that isn't exactly 4 comma-separated values (line 751). WFS 1.1.0 appends the CRS as a 5th element (x,y,x,y,EPSG:3857), so the check fails silently and no spatial filter is applied → all features get returned. That explain the perf issue you saw.

2. Geometry hardcoded to 4326: Lines 1184–1185 always do ST_Transform(..., 4326) regardless of SRSNAME. Meanwhile the JS now assumes coordinates come back in map projection and skips reprojection — so on a 3857 map you get 4326 coords plotted as-is. Thats the mismatch in your screenshot.

Both are pre-existing limitation of the PG path.. Simplest fix imo: add FORCE_QGIS: '1' to the snap WFS call. That bypasses the direct SQL path and goes trough QGIS Server, which handle WFS 1.1.0 + SRSNAME + 5-element BBOX correctly and is also the right place for PROJ/NTv2 datum shifts anyway. Snap is already capped at 1000 features so the extra overhead doesn't really matter here.

Should I make that change and update the test? Fixing the PG path itself (BBOX parsing + SRSNAME awareness) would be worth doing but i'd keep that as a separate issue? I'm keen on migrating the whole snapping function to OL10 soonish.

I'll wait for @rldhont / @mdouchin ..! :)

@meyerlor you are just facing the fact that when QGIS Server returns GeoJSON in EPSG:4326, it truncates coordinates at 6 number after comma. Like I explain here : #6456 (comment)

The solution is to request the GetFeature as GML or to add an SRSNAME and in PHP to force to QGIS Server when SRSNAME is provided.

@meyerlor @rldhont

I'm a little worried about bypassing PG in this case, it's a very useful method for increasing performance.

I'm a little worried about bypassing PG in this case, it's a very useful method for increasing performance.

I agree !

Hi @rldhont @mind84 @mdouchin,
Thanks for the feedback. I worked on both issues raised — the BBOX parsing and the hardcoded EPSG:4326 — directly in the PostGIS path, so the performance benefit of the direct PG query is preserved.

• BBOX with CRS (5th element): getBboxSql now recognises the WFS 1.1.0 format x,y,x,y,EPSG:XXXX. The CRS is extracted and the envelope is reprojected to the layer's native SRID via ST_Transform(ST_MakeEnvelope(..., inputSrid), layerSrid). An explicit SRSNAME parameter takes priority over the 5th BBOX element.
• Geometry output in requested SRSNAME: setGeojsonSql now transforms geometry and bbox to the requested output SRID instead of always using 4326.

Both changes have unit tests covering EPSG:4326, 3857, and 2154.

Is this ok to go forward like this?

My other assumptions about precision were wrong - i closed that PR. (PostGIS ST_AsGeoJSON defaults to 9 decimal digits regardless of CRS.

Hi @meyerlor!

In my opinion, there are no significant issues with modifying the PG function to handle SRSNAME. I think it's worth considering that:

• Precision issues can't be completely avoided; the best solution is to reduce the geometry precision to a fixed grid.

• There are several methods in the code that perform WFS requests; some of these assume the returned geometry is in 4326 format, so it's probably worth doing a general consistency check on these methods.

Cheers

Hi @mind84, thanks for bringin in that perspective!

Both of your points are fair, and I'd rather not widen the scope of this PR to adress them — I think an own issue / PR would be more apropriate?

Like:

• Precision / fixed grid — agreed. ST_AsGeoJSON already caps at 9 digits which is sub-mm for projected CRSes, but an explicit ST_SnapToGrid per
  layer SRID would make output deterministic across reprojections. I can open a dedicated issue to it sooner or later.
• Consistency across WFS callers — also agreed. Several paths still implicitly assume 4326 output (e.g. qgisVectorLayer::editableFeatures(), search,
  osm controllers, plus a few JS consumers). I will start a new issue listing the suspects so we can work through them one at a time - both issues are not top-priority i think?

If that is ok with you, I guess this PR is kind of ready for a final pass. @rldhont @mdouchin — any remaining concerns?