Storing geometries

[geohacker]

This is a proposal for storing geometries as part of the ml-enabler API. We've been doing some thinking around this and think it'd be useful to try this.

In the current design, there are two ways to do this:

1. Store geometries per prediction_tile
2. Store geometries per prediction

Both approaches have their own pros and cons, but I think 2 is likely the winner because:

• Certain models may only have geometries and doesn't want to bother with creating prediction tiles in the db to be able to add geometries
• Polygons for example would have to be clipped at the tile edges if we're indexing geometries at the tile level. Otherwise, there'll be a lot of duplication. If we store geometries at prediction level, we could just store the geometry without clipping.
• Easy to fetch all geometries in a given bbox

Store geometries per prediction

Add another table to store optional geometries produced by Predictors. This would have a schema like:

prediction_id, geometry, properties

Each geometry is a row, linked to the prediction_id.

API to fetch geometries

1. POST /model/prediction/<id>/geometries: accepts a GeoJSON feature collection
2. GET /model/prediction/<id>/geometries: would give all geometries for a given bbox from the prediction

cc @batpad @wronk @xamanu