rmartz
commented
6 years ago Plan for the moment is to use GeoDjango's GEOSGeometry.centroid to select the center of the region, and then use /api/city/nearest/ to turn that into a City ID. This isn't perfect, in part since polygons can be convex and have the centroid external to the polygon, but also because each UserLocation has its geometry defined as a MultiPolygonField.
That's super useful for users because it's the most general type of geometry and most likely to fit their needs, but it also means that a user could pick two completely discontinuous blocks (As anything a MultiPolygonField is needed for inherently contains), and the centroid will almost assuredly be some random spot in between. Not great.
However, that'll probably be an acceptable caveat until we have a chance to iron out some more sophisticated logic to use.
For real-world climate data requests like in #79, we need to know what data to ask for. In the Climate Change API, that is mediated through a
city_id, which abstracts a specific location in the climate data map cell grid. Multiple cities can share a single map cell, but that's OK for our purposes.What we want is to associate
UserLocationobjects with a ID for the city they correspond with in the configured Climate Change API environment, possibly done in conjunction with the creation of theUserLocationobject or shortly afterwards in a batch process (So as to ensure the request/response cycle isn't blocked by a anomalously slow API request)