Finalise initial GeoDjango fields

[griff-rees]

Pull request #69 includes adding a coordinates GeoDjango Point field to gazetteer.Place as an option for spatial queries.

What may be a better fit is a Polygon or MultiPolygon field.

We could then replace the latitude and longitude attributes with methods which return coordinates of acentroid, and the current coordinates could serve that purpose for now. This would provide options for future flexibility in application for other, more complex Place cases. There may be a need for a temporal element for that though (more below).

Other potential options for MultiPolygon fields include:

• gazetteer:
  • [x] County
  • [x] Country
  • [x] HistoricalCounty
• census:
  • Record
  • District (not a current model)
  • SubDistrict (not a current model)

Note: the list above is comparatively easy to switch on for potential use. But: a more robust long-term solution would need temporal elements on how these potentially change over time. One solution for that might be adding a data year or census (etc.) field, and/or another table in between to manage querying with respect to geographic changes over time.

[kallewesterling]

Yeah, this reflects the conversations we had in the summer re: precision about places. Polygon variants = good idea.. Looks like we could even do that server-side (see ST_Centroid) and it would benefit computation-wise?

[griff-rees]

Yeah: GeoDjango just calls the respective SQL operation (see the postgis link under Centroid).

[griff-rees]

Shifting the census side into a separate ticket: #81

[griff-rees]

Closing this given: f52ca9fab89e0a776830deac48833fa2ccd5a9a0