bbox filtering does not work.

GeoServer GeoServer User
1

Hello.
I am very new with GeoServer. It is my first post here and sorry if I am asking something incorrectly.

We (in our Company) are trying possibilities to run GeoServer for Geo spatial data management.

We have installed Geoserver 2.26-SNAPSHOT version on-premise.
then we have configured our MS SQL Server Database which is existing spatial data store in our company. (We are using ESRI platform and we need to compare possibilities of each system.)

Connection to the MS SQL Server Database succeeded and we have imported about 20 layers (database views & tables) into GeoServer without any problem.

All the data is into EPSG:32638 projection.
We have client development on angular + openlayer framework.
We are trying to load data from Geoserver using GeoJSON format and we need to filter features using bbox.

here is the sample url which is generated into client side :

https://11.22.33.44:8124/api-gateway/geo-server/geoserver/socar/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=socar:STATION_EVW&outputFormat=application/json&bbox=41.6160,41.6200,41.6500,41.6450,EPSG:4326&srsName=EPSG:4326

these coordinates : 41.6160,41.6200,41.6500,41.6450 is Batumi City, Georgia.
but the result retrieved is whole georgia. entire data is returned from the server. which is problematic for us. We need that filtering work correctly depend on the bbox parameter.
We tried also CQL_FILTER=BBOX(Shape,41.6160,41.6200,41.6500,41.6450)
but this also does not work.
one of the record :
{
“type”: “Feature”,
“id”: “STATION_EVW.fid–5383551f_196ed95535d_-d44”,
“geometry”: {
“type”: “Point”,
“coordinates”: [44.68991535, 42.08853232]
},
“geometry_name”: “Shape”,
“properties”: {
“OBJECTID”: 13447,
…
}
},

I have checked logs into admin console of the GeoServer. and I see that parameter is handled correctly.

as you can see the point’s coordinate is outside requested bbox.
can anyone has experience with the same problem ?

Regards,
Paata.

2

Hello @paatalom and welcome to the user forum.

I have no recent experience with MySQL, so I wanted to check a couple things, to figure out what we should expect.

Some datastore have the idea of a loose BBOX result, the idea is to return something fast even if some results are outside the area. This allows datastore like Oracle or PostGIS to return results from their spatial index quickly.

To be strict you would use “contains”, which internally uses BBOX to short list candidates, and then performs the slower point-set-theory geometry contains check.

Looking at MySQL datastore implementation BBOX is supported natively, mapped to MBRIntersects function:

            } else if (filter instanceof BBOX) {
                out.write("MBRIntersects(");
                e1.accept(this, extraData);
                out.write(",");
                e2.accept(this, extraData);
                out.write(")");

Perhaps you can look at MBRIntersects documentation to see if it is expected to return results outside of the indicated area.

I also noted:

  • Older version of WFS 1.0.0 being used (not bad just fine)
  • That EPSG:32638 is in easting/northing order (a common source of conduction) . I note the unit is in metre, however your bbox may be in lat / Lon? Not sure if that is what you wanted? The project bounds are 42.0 0.0
    48.0 84.0 and your bbox was in that area - so it feels like you are not requesting the bbox in data space?

Update: Sorry your request indicates bbox=41.6160,41.6200,41.6500,41.6450,EPSG:4326&srsName=EPSG:4326 clearly, so it should be back projecting that to data space of EPSG:32638. When it does so the bbox will get larger in order to be sure to include the required area. Since you are far north this may include significantly more area than you anticipate.

Please compare with contains, it should be slower, but provide less content to transfer.

3

Hello,
I appreciate so much for your quick reply.

In case of CQL_FILTER & Intersection works perfectly :

https://11.22.33.44:8124/api-gateway/geo-server/geoserver/socar/ows?service=WFS&version=1.0.0&request=GetFeature&typeName=socar:STATION_EVW&outputFormat=application/json&srsName=EPSG:4326&CQL_FILTER=INTERSECTS(Shape,POLYGON((41.616 41.620,41.650 41.620,41.650 41.645,41.616 41.645,41.616 41.620)))

I use intersection function directly using polygon and coordinates.
using bbox is more accurate and code looks pretty then this intersection but for me it is ok.

I tried WFS 2.0.0 and bbox but the result was the same.

We have MS SQL Server Database not MySQL .
It is provided by the ESRI platform, is we have to use this database.

Anyway if it is normal to use CQL_FILTER with intersection we are done.
if it is possible to achieve using bbox then it looks more accurate and easy to understand.

Regards,
Paata.

4

Welcome Paata

TIL (today, I learnt) that Batumi City’s lat == long! I was confused by your BBOX at first. It must be tough working in/on a place along this diagonal.

The format is &bbox=minx,miny,maxx,maxy[,CRS]

So your &bbox=41.6160,41.6200,41.6500,41.6450,EPSG:4326 is a bounding box between lat: 41.62-41.645 and long: 41.616-41.65, which presumably is correct.

I don’t have any other advice, other than to use &CQL_FILTER=BBOX(Shape, 41.6160,41.6200,41.6500,41.6450,4326)

Peter

5

It is normal to use CONTAINS, or INTERSECTS is the case of points works fine.

I expect out of my list of ideas the BBOX reprojection from EPSG:4326 to EPSG:32638 produces a bigger area then you expect returning more points.