Plone 5 and GIS

Plone Support Add-on Development
1

I'm working on a solution which needs to display points within a bounding box.
I'm looking for some guidance or suggestions.

Use case is as follows: I have a content type which has a Longitude and Latitude field. Based on this I'd like to be able to display the items whose Long/Lat fit within a bounding box.

So far I've narrowed it down to two options:

Option A - Use Postgis for the GIS data

This seems to be the quickest solution and the one I'm inclined towards (but I'm still open to an alternative).
PostGIS and Postgresql, it's easy to install, known quantity, made for this purpose and bulletproof implemantation.
I'd just write a custom view that interacts with my content types. But it means adding Postgresql to my stack.

Option B - Use Python and a Python Library

I'm looking at Geopandas or Rtree as a backend to a ZODB catalog index.
Rtree might not be ideal and it would
be reimplmenting database functionality built into Postgis.
Additionally it feels more like an unknown quantity when compared to Option A.

Geopandas might be able to do it but it requires more research, also time unknown.
Similar things have been done: https://mail.zope.org/pipermail/zodb-dev/2010-June/013491.html

There is an implementation which depends on Rtree but I don't know if it has been ported to Plone 5

Option C - something I'm missing

And of course there's Option C which would be something I haven't looked at.

2

Option d: two number indexes in the catalog and range queries. Its not really that hard.

3

I like Option D :slight_smile:

4

Decided to look again at the problem before adding PostGIS to the stack.
My content type already has longitude and latitude fields.

Here's what I did so far

  1. Created an custom catalog index which indexes longititude/latitude
  2. Updated an exisiting view to return GeoJSON with the points I want based on a queries
  3. Using leaflet.js I can find the bounds of a list of points (returned in GeoJSON format from my endpoint)

So far no need for Postgres/Postgis...

My biggest concern is when the browser needs to deal with large numbers of points, but I don't think that would be less of a problem with a PostGIS backend.

5

Not sure about other apis, but when we needed a lot of points with google maps we used KML. Worked well. - https://developers.google.com/maps/documentation/javascript/examples/layer-kml

6

I dont think this suits your need, but 'just in case'....
There might be an option C that could be useful for 'some things', numpy/mathplotllib:


http://matplotlib.org/basemap/users/examples.html

7

Thanks @espenmn
Your suggestion is pointing me in the right direction (I think). I now have a function that can filter based on a bounding box. Numpy is pretty useful :slight_smile:

Next I'll want to optimize this.

8
9

@cleder,
I was a bit worried about Rtree, the trac page doesn't exist anymore and it doesn't seem maintained. Also the fact that collective.geo.index hasn't been touched for 4 years. I also noted that collective.geo.bundle (which works with Plone 5) doesn't list collective.geo.index as a dependency. Would love to hear your perspective on that especially since it looks like you're the author.

10

Rtree was updated quite recently https://pypi.python.org/pypi/Rtree/ (and is anyway just a wrapper around https://github.com/libspatialindex/libspatialindex) which is also still actively supported. as for c.g.index you may want to have a bit of review what has changed since the last update and port it to the latest plone zcatalog (c.g.index is also only a thin wrapper to integrate Rtree into zcatalog so I think there is not a lot to learn to get you up to speed)
To run c.g.index you will need to have shapely => libgeos and other dependencies installed, On linux this is usually not much of a problem

11

Hmm... I'm almost finished (hopefully less than an hour) with a NumPy implementation of what I need, that said, having c.g.index in my back pocket for the future might be valuable. It's encouraging to know that the supporting stack is still viable.

12

I would probably change the storage implementation to http://toblerity.org/rtree/tutorial.html#zodb-and-custom-storages

13

so the difference with an rtree is when you want to store boxes rather than points and do intersection queries? for simple points you can get buy with just lat or long indexes right?

14

yes that should be fine.