Add fields + custom behaviour at organization level to define default spatial data

[Hoedic]

Define a geospatial BBox in geojson at the organization level. It is not to be displayed in the page, but the bbox could be assigned to the "spatial" fields of the datasets owned by the organization (if the spatial field was not filled when the dataset is created/updated)

[deniszgonjanin]

We should talk a bit more about what Geospatial features exactly will the site need. Right now I know we are doing:

• KML previews
• BBox extent for organizations, for search purposes.

Now, ckanext-spatial with PostGIS has not been updated for CKAN 2.3. One problem is the resource views - ckanext-spatial is still using previews. Another problem is that spatial is still only compatible with PostGIS 1.x and PostgreSQL 8.x, while we are using Postgres 9.x for some other features.

The two features in the list above can both be accomplished without ckanext-spatial. For previews, I am looking at modifying ckanext-geoview, and for the second it's possible to do bounding box geo search purely via solr.

So we should find out how much more geospatial features we need, as it might be possible to avoid needing PostGIS altogether, which would mean we don't need to bother fixing ckanext-spatial for 2.3

[Hoedic]

Ok, those are import points (not updated with 2.3, postgres/postgis version differences) we should discuss these points at the next call. To answer the question "what is expected to come with ckanext-spatial:

• It was initally said to the participants that geojson visualisation would be available. For the moment, geojson is presented as the default geo format to be used by publishers.
• Government of Québec currently provides its catalogue in non-valid DCAT and CSW and they expect to be able to do harvesting. We have to evaluate from which platform and how they want to harvest to CSW harvesting.
• I am not 100% sure how you expect to do geofiltering without postgis.

I don't know if you tried to install ckanext-spatial on postgresql 9.x/postgis2 but in theory it is backward compatible. Postgis 2.x comes with new ways to declare geometries but still supports the old one.

[deniszgonjanin]

Need to take a look at geofiltering using Solr

[Hoedic]

For the moment a "bbox" field has been added at the organization level, not use for the moment however.

[deniszgonjanin]

I don't know why IPackageController doesn't have a before_create hook like IResourceController does. after_create and after_update happen after data has already been committed, so altering the dataset again would result in an infinite loop.

I'll have to think more about this. What is the use case for the bbox?

[Hoedic]

I'll have to think more about this. What is the use case for the bbox?

1. Is to have as complete metadata as possible
2. It's not being activated yet, but it would make possible to use geofiltering feature.

As said, not a huge deal.

[deniszgonjanin]

The best thing I can think of at the moment is to have a bbox field on the dataset level as well. In before_index, if the dataset-level field is empty, insert the bbox of the parent organization.

This would work if geofiltering is done via Solr, but if it's to be done with PostGIS, a different solution would be needed.

[Hoedic]

There is an equivalent of the bbox field at the dataset level (which is "spatial", same name as used by the spatial extension).

Tell me if I'm wrong, but before_index only alters the dict sent to Solr, which means that Solr would get the added spatial/bbox field at the dataset level, but in CKAN (in the CKAN DB), the field would remain empty. Is that correct?

[deniszgonjanin]

Yes, that's right. It would only be useful if the spatial filtering was done through Solr