Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.This module should be able to take the standard bounding box variable sent by a GetFeature or FeatureInfo request, and only return points inside of it.
| Comment | File | Size | Author |
|---|---|---|---|
| #6 | wfs-filter-changes-2.patch | 5.01 KB | ahtih |
| #2 | wfs-filter-changes.patch | 4.86 KB | ahtih |
Comments
Comment #1
tmcw commentedThis change introduces the fundamental XML parsing:
http://drupal.org/cvs?commit=345298
Comment #2
ahtih commentedAs I understand, the CVS version (DRUPAL-6--1) has bbox-filtering partially implemented, but commented out. When uncommenting, it works fine for me, after some modifications which I attach as a patch. However I do not expect tmcw to commit it as-is, as there are some controversial changes. The patch that does the following:
* uncomments filter functionality
* changes OpenLayers-specific part of XML parsing; the version in CVS fails parsing filters generated by latest OpenLayers.Protocol.WFS
* swaps filter input BBOX coordinate ordering from "lat,lon" to "lon,lat". This might break code. But since WFS module itself uses "lon,lat" in GetFeature response, it would be strange if filter expected a different ordering. OpenLayers.Protocol.WFS can be configured with either ordering, but forces filter to use same ordering as GetFeature response.
* makes filter to support data source being Geo lon/lat fields. The version in CVS fails there in 2 aspects: 'function' is not set in filter, which makes Geo to apply its default 'distance' filter instead of 'x' or 'y'; and 'units' is not set in filter, which makes Geo to assume its default of 'miles' and converts values to 'meters'. Thus when trying to e.g. specify "geofield.latitude >= 10.0", the CVS version generates SQL "ST_Distance_Sphere(geofield, GeomFromText('POINT(0 0)', 4326)) >= 16000" which obviously returns completely wrong results.
Next I intend to make the filter support Geo WKT data source, with database spatial index.
tmcw, WDYT, am I going in the right direction?
Comment #3
ahtih commentedFYI, Geo lon/lat support also needs Geo to be patched as per http://drupal.org/node/883010 for it to fully work.
Comment #4
tmcw commentedSure, when the Geo module accepts the patch, I think that this is a good idea on the part of this module, as long as this doesn't break compatibility with datasources other than Geo. I don't use Geo, since it breaks down the idea of data modularity that Views tries to build, but I'd guess that a lot of users are interested in compatibility.
Comment #5
ahtih commentedThanks. Let's see if/when one of Geo maintainers reacts to the Geo patch.
WDYT about points 2 and 3 of my changes list (XML and lat,lon)?
Comment #6
ahtih commentedAttaching a new version of this patch, with better XML error checking.