Adds a new map widget to the 2.0 search templates. It is shown initially
in the sidebar but it is expanded when the user needs to draw an area.
It uses Leaflet and Leaflet.draw.
Otherwise you get this exception when the date on the document has time
zone information, as dates as stored without it on the database:
TypeError: can't compare offset-naive and offset-aware datetimes
This backend does not use the spatial field on Solr, but indexes the
area and coordinates of the dataset's extent. On query time, a boost
function is used to calculate a ratio between the query area and the
dataset extent, which will give a value of 0 for areas that don't
overlap and 1 for a perfect fit. The same function is used both for
sorting and filtering.
To return correct results on a spatial query, rectangle geometries must
be defined in counter-clockwise order [1]. This changeset adds a small
sanity check to before_index when we are dealing with a Polygon geometry
that has 5 coordinate pairs. Shapely is used to generate a LinearRing
from the polygon coordinates and check if they are ccw. If not, they are
reordered and a new polygon is generated so the WKT sent to Solr is
properly ordered.
The GeoJSON template used for extents in the base spatial harvester has
been also updated to define the coordinates counter-clockwise.
[1]
http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4#JTS_.2BAC8_WKT_.2BAC8_Polygon_notes
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 common problems:
* Whitespace, tabs, line feeds and plus signs: should be handled by
float()
* Text: log error and skip creation of spatial extra
* Same set of 2 coords for extent: create point instead of polygon
Note that the bbox values are stored as they are in the bbox-xx-yy
extras
The 'guess_resource_format' function looks for common patterns in popular
geospatial services and file extensions. It just looks at the provided URL,
it does not attempt to perform any remote check. By default, it will use the
mimetypes module if no match was found before to try to guess the format.
On the previous version, all resources in documents of type 'service' were
queried to see if they were actually WMS. This is no longer the case,
but services flagged as 'wms' can be verified if the following setting
is set to True: ckanext.spatial.harvest.validate_wms
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
The import CLI reruns the import stage for the last current objects, so
when running it, the previous objects don't need to be changed. Any
date check is overridden to force the update of the package.
This can be set instance wide on the ini file with
ckanext.spatial.harvest.continue_on_validation_errors
or per source, adding continue_on_validation_errors=true to the source
config.
amercader
Ian Ward
kindly