[Bug] v.in.wfs with -r flag

[saudeoud]

Describe the bug

v.in.wfs -r doesn't work in my case (srs 2154). The fetched data contains 0 feature.

To reproduce

set up a EPSG 2154 LOCATION

g.region n=6394000 s=6393000 e=991000 w=990000

v.in.wfs -r url="https://data.geopf.fr/wfs/wfs?"  output=cbn  name=ELEVATION.CONTOUR.LINE:courbe version=2.0.0 srs="EPSG:2154" 

Expected behavior

download data in 2154 srs, in the current region

System description

• Operating System: debian bookworm
• GRASS GIS version: grass master

Suggested Solution

Working URL is :
https://data.geopf.fr/wfs/wfs?REQUEST=GetFeature&SERVICE=WFS&VERSION=2.0.0&TYPENAMES=ELEVATION.CONTOUR.LINE:courbe&srsName=EPSG:2154&BBOX=975902.5,6389002.5,1023002.5,6426102.5,EPSG:2154

1. "&srsName=" should be parsed instead of "&SRS="
2. In case the CRS of BBOX coordinates is not in the defaut CRS of the requested data, CRS must be given at the end of the bbox parameter

see https://docs.geoserver.org/main/en/user/services/wfs/reference.html

Note that srsName is the srs for the fetched data, potentially different of the BBOX srs specification at the end of the bbox parameter, which stands only for the bbox coordinates. Though, it makes little sense to use 2 different values in this case.

More generally, I don't understand the need of parsing the desired srs, as it can be automatically deduced from grass location. But maybe there are some uncommon usages of the module that make use of this possibility.

Additional feature suggestion

It could be usefull to add an option to clip all data to match with current region extent

[sudhanshu112233shukla]

Fix v.in.wfs -r flag to correctly use srsName instead of SRS

• Replaced &SRS= with &srsName= in the WFS request URL.
• Ensured that the BBOX parameter includes an explicit CRS at the end.
• Fixed compatibility with WFS 2.0 as per OGC standards.
  I am interested in working on this issue. Let me know if any additional changes are needed.

[saudeoud]

Thanks a lot
I will see this in few days
Regards