layerFilter (CQL) - Inconsistent SRID Requirement (WFS vs WMS)

19 views
Skip to first unread message
Assigned to matteo.v...@geosolutionsgroup.com by lorenzo...@geosolutionsgroup.com

gaetan....@gmail.com

unread,
May 20, 2025, 6:08:55 AMMay 20
to mapstore-developers

Hi,

As part of a contribution, I’m using MapStore filters (layerFilter) in CQL format.

> see more details in https://github.com/geosolutions-it/MapStore2/pull/10515

The goal is to filter the attribute table using a WKT and to synchronize the map accordingly.

However, I’ve identified an issue related to the CQL syntax.

The WFS request for the attribute table does not require specifying the SRID in the CQL, since the SRID is already defined in the XML of the request being sent.

But the WMS request used by the layer (CHANGE_LAYER_PROPERTIES) always requires SRID 3857 (I don’t understand why), even if the layer is published in EPSG:4326. In this case, the SRID must be explicitly specified in the CQL filter.

- Example of a layer filter that works for the attribute table with simple CQL body :

{

  "filtertype": "OGC",
  "filters": [
    {
      "format": "cql",
      "body": "INTERSECTS(geom,POLYGON((2.4061751338097164 48.8994962820134, 2.4061751338097164 48.88576454618643, 2.4468245562541195 48.88576454618643, 2.4468245562541195 48.8994962820134, 2.4061751338097164 48.8994962820134)))"
    }
  ]
}


- Example of the required CQL filter that works for synchronizing both the map and the attribute table (need \"geom\",SRID=4326 SRID argument) :

{
  "filtertype": "OGC",
  "filters": [
    {
      "format": "cql",
      "body": "INTERSECTS(\"geom\",SRID=4326;POLYGON((2.4061751338097164 48.8994962820134, 2.4061751338097164 48.88576454618643, 2.4468245562541195 48.88576454618643, 2.4468245562541195 48.8994962820134, 2.4061751338097164 48.8994962820134)))"
    }
  ]
}

This behavior is undocumented and makes the developer experience more difficult, reducing the reusability and simplicity of using layerFilters.

But it’s likely that I’m not using it correctly.

Reply all
Reply to author
Forward
0 new messages