When the 'ckanext.spatial.search_backend' config option is set to
'solr', the extension will index geometries stored in the 'spatial'
extra on the spatial field of the Solr index (named 'spatial_geom').
This is done on the 'before_index' extension point.
Also, when doing a query, if the same config option is in place, the
necessary fq parameter will be set to pass the spatial query to Solr.
Some improvements on the endpoints that return the contents of the
harvest objects:
* Nicer URLs with redirects to the old ones
* Returning the raw harvest object content is available on the main
harvest extension, so just redirect there
* Support for showing the original document of a harvest object, if
present
* Suport for defining a custom XSLT for the HTML view, via
ckanext.spatial.harvest.xslt_html_content
ckanext.spatial.harvest.xslt_html_content_original
- Added a config option ('ckanext.spatial.use_postgis_sorting') to
activate this as this behaviour will be deprecated in the future
in favour of Solr 4 spatial sorting capabilities.
Also fixed the tests
Conflicts:
ckanext/spatial/plugin.py
Tests are passing, apart from a couple which didn't work before:
* test_functional.py -> functional/test_package.py (3 failures in 4)
* functional/test_dataset_map.py (1 fail in 1)
There may be some code errors still untested.
Renamed Validator -> Validators to make more sense.
If filtering the results after the search, recalculating the facets
is too complicated, so we use the alternative approach of doing the
spatial search first and adding the ids as a filter in the Solr query.
Search results coming from the default CKAN search (which are received
via the `search` method of the `IPackageController` interface) are
filtered to only contain the ones intersecting the provided bbox.
The search form temporarily shows a text field, which will be replaced
by a nice map widget.
The spatial_query plugin now automatically checks for the existance of an
'spatial' extra when creating, updating or deleting a package and syncs its
value (in GeoJSON format) with the geometry column of the package_extent
table. The extension now uses GeoAlchemy, that makes performing spatial
operation extremely easy. The geometry field has been updated to support
multiple geometry types (Polygons, Points, MultiPolygons...) and the default
srid has been set as WGS 84 lat/lon (EPSG:4326).
amercader
David Read
David Read
james gardner