[ckan-dev] [ckanext-scheming] Feature request: spatial widget (#11)

Thu Jan 15 03:49:13 UTC 2015

Hi all,

could I ask you all, especially the ckanext-spatial and -scheming crew for
advice.

My CKAN users love georeferencing their datasets, but, being environmental
scientists with sometimes limited GIS skills, some struggle with pasting a
correct GeoJSON geometry into the "spatial" extra field. So, with guidance
from Ian I've prototyped a spatial input widget which you can see in action
at [0] and take for a spin at [1] with un/pw "ckan".

The widget still shows the text input for a GeoJSON geometry (enlarged into
a textarea), but also adds a map one can draw the dataset's extent on, and
a select box for often needed, well-defined areas.

This widget depends on a few components which may or may not belong into
ckanext-spatial or -scheming.
ckanext-spatial PR at [4]
- A module spatial_form (based on spatial_query)
- Updated Leaflet.draw, which requires an updated LeafletJS (and breaks
spatial_query)
- Fixing spatial_query to work again with backwards-incompatible
Leaflet.draw

ckanext-scheming feature request at [5]
- A new form snippet spatial.html [3] which depends on spatial_form to
render the map, but also renders a select for pre-defined areas, and
contains the JS to data-bind the inputs together.
Also I've included display snippets, which render the dataset's extent
inline (see video), which replaces the dataset's extent as facet in the
sidebar.

The whole setup works well enough on my end, but before I can send a
clean(er than [4]) PR I'll need your advice on a few points:

Should all components of the spatial widget live in ckanext-scheming, or
which components would be appropriate as PR in ckanext-spatial?

What is the official procedure for upgrading JS dependencies in extensions?
Is there a more graceful way than overwriting files in /vendor/ ?

As for data-binding the three input widgets (map, select, textarea), should
we use heavier artillery like react.js or will we get away with a few
manual JS hooks? Note in my prototype I've only bound map->text and
select->text, but not select (in scheming) to map (in spatial).

As for the select box, that really should also live in the spatial_form JS
module, right? I kept it in ckanext-scheming's form snippet for now, as
it's a ckanext-scheming select widget with data coming out of my custom
data schema definition. Of course that's clunky and hard to maintain, so
I'd rather have a custom vocabulary with an API (for maintenance) and an
autocomplete service (for the input), much like tags, but we'll need three
values (id, label, GeoJSON geometry/string) instead of two, like tags (id
and label).
Would it be feasible to have an autocompleting custom vocabulary for
spatial entities, and how would I implement this without interfering with
models?

Cheers,
Florian

[0] Spatial widget in action (apologies for potato quality)
http://vimeo.com/florianwmayer/ckan-georeferencing
[1] Demo instance http://data-demo.dpaw.wa.gov.au/
[2] spatial_form JS module
https://github.com/florianm/ckanext-spatial/blob/91-spatial-form/ckanext/spatial/public/js/spatial_form.js
[3] spatial form snippet
https://github.com/florianm/ckanext-scheming/blob/master/ckanext/scheming/templates/scheming/form_snippets/spatial.html

[4] PR ckanext-spatial https://github.com/ckan/ckanext-spatial/pull/93/
[5] Feature request at ckanext-scheming
https://github.com/open-data/ckanext-scheming/issues/11

On Thu, Jan 15, 2015 at 2:30 AM, Ian Ward <notifications at github.com> wrote:

> here
> <https://github.com/open-data/ckanext-scheming/issues/11#issuecomment-66448057>
> I said this should be separate from ckanext-scheming, but this looks so
> nice I'm changing my mind. It would be great to have a good standard
> spatial input and view like this in scheming itself, since users are still
> free to extend or replace it in their own extensions.
>
> If most of this work applies to ckanext-spatial users that might not be
> interested in scheming, though, then it's probably better not to duplicate
> it.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/open-data/ckanext-scheming/issues/11#issuecomment-69965596>
> .
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/ckan-dev/attachments/20150115/15bb001e/attachment-0002.html>