Filter bbox coordinate order needs to follow CRS
Closed this issue · 4 comments
Could it be that the current bbox (bounding box) filter implementation in TiFeatures expects the parameters to be in order xmin,ymin,xmax,ymax?
We are experiencing an issue that a client (QGIS) is formatting the request such that the order of the coordinate values follows the CRS, which in the case of 4326 is minlat,minlon,maxlat,maxlon, i.e. ymin,xmin,ymax,xmax. 😩
A request with the wrong order causes a 500 error with TiFeatures.
It appears that the bbox order needs to follow the CRS per WFS/OGC Features standard. I have not dug into the specs but found this in the GeoServer docs:
The BBOX parameter allows you to search for features that are contained (or partially contained) inside a box of user-defined coordinates. The format of the BBOX parameter is bbox=a1,b1,a2,b2,[crs] where a1, b1, a2, and b2 represent the coordinate values. The optional crs parameter is used to name the CRS for the bbox coordinates (if they are different to the featureTypes native CRS.) The order of coordinates passed to the BBOX parameter depends on the coordinate system used (this is why the coordinate syntax isn’t represented with x or y.)
Also, Even says so: qgis/QGIS#33673 (comment) 😉
There seem to be many places in TiFeatures where xmin,ymin,xmax,ymax is hard-coded:
we choose not to implement OGC part2 (https://docs.ogc.org/is/18-058r1/18-058r1.html) of the Feature API so we assume the CRS to be always Lon/lat.
Now that tifeatures and timvt are merged into tipg we do have pyproj (from morecantile) available so we could support it in theory. BUT I'm still 🙅 about adding CRS into geojson.
Can we not adhere to the CRS-defined axis ordering for EPSG:4326 even without supporting (other) CRS?
WFS 1.1.0 and WFS 2.0.0 apparently adhere to the axis order, so if a client implements that version, TiPG will not support bounding boxes, even in EPSG:4326, which is a big limitation, IMO.
GeoServer docs have the overview: https://docs.geoserver.org/latest/en/user/services/wfs/axis_order.html#wfs-basics-axis
@j08lue Let's not mix the specifications here, tipg is trying to follow the OGC Features API not the WFS specification
QGIS seems to follow the OGC core spec (https://docs.qgis.org/3.22/en/docs/server_manual/services/ogcapif.html) so I don't think there are any issue here
turns out there is a bug in tifeatures/tipg #30