Opened 19 years ago

Last modified 14 years ago

#1287 closed defect

MAP EXTENT truncates GetFeature requests for data outside bounds — at Version 3

Reported by: tomkralidis Owned by: tomkralidis
Priority: high Milestone: 6.0 release
Component: WFS Server Version: svn-trunk (development)
Severity: normal Keywords:
Cc: assefa, sdlime, mapserverbugs, bartvde@…

Description (last modified by sdlime) 

If data in a given layer is outside the bounds of the MAP/EXTENT object, this
data is not included in a blanket GetFeature request, i.e.:

http://[host]/mapserv?version=1.0.0&service=WFS&request=GetFeature&typename=roads

It should be.

Change History (3)

comment:1 by tomkralidis, 16 years ago

Cc: assefa sdlime mapserverbugs added
Milestone: → 5.2 release
Owner: changed from mapserverbugs to tomkralidis
Status: new → assigned
Summary: [WFS-Server] MAP EXTENT truncates GetFeatutre requests for data outside bounds → MAP EXTENT truncates GetFeature requests for data outside bounds
Version: unspecified → svn-trunk (development)

I can confirm that this behaviour still exists.

Thinking about this again, I wonder what our best approach is here. Even though the layer bbox does not overlap MAP/EXTENT, there _is_ data there, in accordance to what a WFS client thinks should be returned (i.e. all data).

I guess this leads us to the question: what relevance does MAP/EXTENT have in WFS Server (mapwfs.c)?

Comments?

comment:2 by tomkralidis, 16 years ago

Cc: bartvde@… added

comment:3 by sdlime, 16 years ago

Description: modified (diff)

Depends on the query type. For attributes the extent is used as a pre-filter before any attribute-based filtering is done. Does WFS just wrap the msQueryUsing... functions or does it have it's own processing logic? I assume the latter since it supports spatial filters that the CGI-based query modes do not.

What sorts of OGC filters are we talking about here?

Steve

Note: See TracTickets for help on using tickets.