Spatial unit data modelling and API

[ian-ross]

Part of #172, broken out for tracking and assignment.

• Create new spatial Django app and include in project configuration.
• Spatial unit model (modifications from data model sketches to include geometry data quality?).
• Spatial relationship model.
• TEST Spatial unit model creation (create spatial units of different types, with and without geometry).
• TEST Spatial unit relationship creation (create spatial units and different relationships between them).
• TEST Spatial unit relationship traversals (check traversal via SpatialUnit.relationships field: can you get from a spatial unit to the unit it's contained in? to the units it contains? to the unit(s) it was split from/into? to the unit(s) it was merged into/from?).
• Custom manager for spatial unit relationships to maintain the integrity of spatial relationships for spatial units that have geometry of a certain quality level (see Note 1 below).
• TEST Spatial unit relationship integrity maintenance (pass/fail for different types of geometry and different types of spatial unit relationship).
• Spatial unit and spatial unit relationship test fixtures.
• API documentation: write up as part of design process.
• API design: serialization format for spatial units.
• API design: list spatial units (GET /organization/<org-name>/project/<proj-name>/spatial/), including query options (filter by attributes, type, etc. plus spatial filtering).
• API design: view individual spatial unit (GET /organization/<org-name>/project/<proj-name>/spatial/<unit-id>).
• API design: create spatial unit (POST /organization/<org-name>/project/<proj-name>/spatial/).
• API design: update spatial unit (PUT/PATCH /organization/<org-name>/project/<proj-name>/spatial/<unit-id>).
• API design: delete spatial unit (DELETE /organization/<org-name>/project/<proj-name>/spatial/<unit-id>).
• API design review
• DRF serializer for spatial units
• TEST DRF serializer for spatial units (good and bad data to serializer/deserializer in both directions: check error conditions, check accurate data serialization and deserialization).
• Design permissions for spatial units for use in DRF views.
• API views: get individual spatial unit.
• TEST get individual spatial unit view (success, non-existent unit, non-existent organization and/or project, permissions pass/fail).
• API views: create spatial unit.
• TEST create spatial unit view (success, non-existent organization and/or project, permissions pass/fail, valid/invalid upload data, including invalid geometry).
• API views: list spatial units (basic).
• TEST basic list spatial units view (success, non-existent organization and/or project, permissions pass/fail)
• API views: list spatial units (query parameters: sort, filter, search).
• TEST full list spatial units view (look at the organization or project tests for ideas, but also include spatial filtering queries).
• API views: update spatial unit (includes making sure that serializers work for partial updates).
• TEST update spatial unit view (success, non-existent organization, project and/or spatial unit, permissions pass/fail, valid/invalid patch data, including invalid geometry).
• API views: delete spatial unit (just implement this as a "normal" delete to start with -- we'll worry about logging, history and so on later).
• TEST delete spatial unit view (success, non-existent organization, project and/or spatial unit, permissions pass/fail).

Notes

1. Suppose that you have spatial units A and B, both of which have high-quality polygonal geometry. Suppose that you attempt to create a spatial unit relationship saying that spatial unit B is contained within spatial unit A. Creation of the spatial unit relationship should fail unless the geometry of B is spatially contained within the geometry of A. Similarly for merge/split relationships, and similarly for containment relationships between an "outer" spatial unit with polygonal geometry and "inner" spatial units with only point geometry.

[linzjax]

Update since I'll be out next week:
Things left unchecked about API design review:

Spatial unit model (modifications from data model sketches to include geometry data quality?).

• Done except for geometry data quality

API documentation: write up as part of design process.

• Done based on what's currently finished, but the validation errors need to be updated to reflect something more helpful.

API design: serialization format for spatial units.

• Done except for validation, but should be reviewed by someone who knows better than me.

API design: list spatial units (GET /organization//project//spatial/), including query options (filter by attributes, type, etc. plus spatial filtering).

• Not sure what spatial filtering meant, but done outside of that.

API design: delete spatial unit (DELETE /organization//project//spatial/).

• It's working, but throwing up a mess of errors when it's successful.

Side note: currently everything is running through

organizations/{organization-slug}/projects/{project-slug}/spatial/{spatial-id}/

but could be adjusting to run through

spatial/{spatial-id}/

I just kept it simple so I could figure out how things worked, but I could refactor it if that url is preferable.