Should the project geometry/extent be required?

[seav]

Forked from #59.

Currently the Project model does not set geometry as a required field. Is this still the case? Looking at the larger picture, what exactly is the purpose of the project geometry field? Some use cases mentioned in other issues are:

• To show a zoomed-in map in the project overview (Zoom map to project extent #276)
• To act as a check that locations are within the project's bounds (Locations should not be created outside project geometry #343)

[wonderchook]

For now this should be required. Later when we address some of the issues in #343 we can rethink if this is the case.

[seav]

We shouldn't flip-flop on whether to make the geometry required. This adds/removes constraints on the Project model and will trigger data migrations, which we should try to avoid.

[ian-ross]

Whether changing our minds about this later is a problem depends on how we implement it. If we do the "spatial unit in project extent" check in a Django custom manager, it's not a constraint that appears in a database migration anywhere, so it's not a problem to add or remove it. On the other hand, if we implement the check directly in the RDBMS, switching back and forth will require migrations. And the migrations will potentially be quite complicated, because we'll have to implement the constraints by hand (i.e. by writing custom SQL), since this sort of thing isn't directly supported by the Django ORM, as far as I can tell. We'd probably need to add a custom database function to do the check and use a generic CHECK constraint on the geometry column of the spatial unit table. Something like the more complex case shown here: http://www.spatialdbadvisor.com/postgis_tips_tricks/127/how-to-apply-spatial-constraints-to-postgis-tables/ including the "check against geometry via a foreign key reference" part. It's not insurmountably difficult, but it will require care to get it right. (For information, CHECK constraints are described here: https://www.postgresql.org/docs/current/static/ddl-constraints.html)

If we do decide on having this constraint, my preference would probably be to implement it in the RDBMS. This is mostly because we're starting to get to the point where we need to be a bit more careful about efficiency, and applying these kinds of constraints in a custom manager leads to more round trips to the RDBMS.

[wonderchook]

I'm not sure we really want to require a the spatial unit be in the project extent. My concern about the project extent not being required is the experience of the user when they are on the map pages. If there isn't an extent where do we put them out to?

[ian-ross]

OK, so how about we say (for now, at least) that we don't have any spatial constraint on spatial units, so they don't need to lie within the project extent, but that we do require all projects to either have an explicit project extent, or to have a flag marking them as global? (Or we just change the language on the project add extent geometry view to strongly encourage users to provide a project extent for their projects? That would be even easier!)

[wonderchook]

I like the "strongly encourage option" I think that works.

[ian-ross]

That's great. That means we don't need to make any code changes at all to close TWO issues, just change some words!

[ian-ross]

I've assigned this to @clash99 since she's been doing a lot of the "words" changes on other pages, and so is probably most familiar with the style of the text in the templates right now. Fell free to reassign it to someone else if you like!

[clash99]

I will change the messaging on the page to strongly encourage a boundary.

Depending on feedback from usability testing, we may want to consider an error-type message that gives the user the option to go back and add a boundary if they didn't with the benefits of doing so listed... but not required.

[clash99]

How does this look for the messaging? Ideally we will be including a tutorial-type link here to show how to use the map tools to mark a boundary.

Encouraging message: If your project is not global, we encourage you to mark your project boundaries. This will facilitate your project's map interactions and help others to easily locate your project.

Thoughts?

[seav]

I think this messaging looks good.

[ian-ross]

How about: We encourage you to mark the boundary of your project (if your project is not global). This makes map interactions simpler and also helps other users to find your project.

[wonderchook]

I'm wondering if people would know what "project is global" is immediately or if they don't have enough information. Use what I've added before.

"We encourage you to mark the area in which your project takes place (if your project doesn't doesn't include the entire world). This makes interactions simpler and also helps other users to find your project."