Allow grouping of areas as one concept

[dracos]

What we really want is for the Area model to be called Geometry (the Geometry model exists because old versions of postgres were very bad at multipolygon PinP; it could be called Polygon I guess), and a new Area model to exist which can refer to multiple Geometrys. This would allow e.g. use of OpenStreetMap relation IDs to consistently refer to an area, and allow council boundary changes in the UK (as opposed to ward boundary changes within a council) to maintain the same identifier for the council more easily.

[dracos]

One alternative/possibility is that we could already have this grouping, in that areas can have parents, with no generational constraints otherwise. So you could have:

• Area: Glasgow City Council, generations 1-30, no associated geometry, has e.g. local-authority-eng code.
  • Area: Glasgow City Council, generations 1-14 (mapit.mysociety.org/area/141651), has GSS code
    • Areas of the wards of Glasgow generations 1-14
  • Area: Glasgow City Council, generations 15-30 (mapit.mysociety.org/area/2579), has GSS code
    • Areas of the wards of Glasgow generations 15-30

/point or /postcode would return the same as now, because the 'parent' area has no associated geometry – so you'd need code change to return this new parent somehow. And so you'd be getting two responses for one council, so perhaps this is too confusing.

One big (the main?) user that has this issue is FixMyStreet – it would certainly be possible to move to these parent identifiers if they existed, and this would provide greater stability for the next council GSS ID change (when because we didn't want to change FixMyStreet, we bodged MapIt to put the new boundary in the old ID and the old boundary in a new ID, I know).

If this solution was acceptable, it would be much more straightforward than anything else.

And following on from #235, you could have a CA be a parent of those stable identifiers (for that particular case).

For the more general #7, e.g. police areas, an issue there is that the police area is defined as a combination of councils (ie. their stable identifiers, whatever their boundary may be) – so you would want that to be possible to prevent having to update them whenever a council GSS changed. One option – multiple "parents"; another option, a separate combination lookup table of some sort.

[dracos]

Except what about someone wanting the wards of Glasgow, holding Glasgow's 'stable' ID? They should be able to call children on it and get them, surely. So that leads to:

• Area: Glasgow City Council, generations 1-30, no associated geometry, has e.g. local-authority-eng code.
  • All areas of the wards of Glasgow, whatever generation (the children call lets you look up previous generations with a parameter)
  • Area: Glasgow City Council, generations 1-14, has GSS code
  • Area: Glasgow City Council, generations 15-30, has GSS code

Which means that someone making a children call for Glasgow (with no type filter) would get two Glasgow, which makes little sense to a casual user, or is it okay? It's probably not okay.

[torotil]

Naive question: Isn’t it as simple as having these conceptual areas as described above but making them report only as one area depending on the generation that is queried? This would mean that for any given generation the Area can only have one child.

Maybe it’s even cleaner to don’t call the new concept "Area" and represent it as an entirely different entity.

[dracos]

In my occasional return to this topic, how about this:

1. Add a Concept table, with name and a m2m table to itself, called, dunno, 'Combinations'
2. Add a concept_id to the Area table, that links to the Concept table
3. (For the UK) Create a Concept for each council in MapIt, with the same ID as its current generation Area(!) linked to the relevant Area. And link all other Areas for each council to its Concept.

This is basically the solution as in the original ticket I wrote, I think, so, umm, hohum.

• point or postcode lookup - this would return the same areas as present, including as extra data within an area its linked concept if any. It would also additionally have to return - as extra results - Concepts that come from the Combinations table (e.g. a police area that is defined as the combination of a number of councils), and would need a way for IDs not to overlap. I don't think we've ever said IDs would always be numeric, so that would be easiest, but might well break some usage?
• Area geometry - for a concept would redirect to its most recent generation entry (or could be given a generation ID?). /area/[IDs]/geometry, hmm, rewrite any concept IDs in the URL? Or have separate concept URLs...
• Area children - conceptually, children are children of a concept, but in the db are children of areas. So given a concept ID, redirecting to most recent generation entry and then that's children would work same as now, really.
• Type and name lookup - hmm. For consistency, should return same as now, with extra concept data included in each area if relevant, and then people can decide what to do with them.

What have I missed.

As a worked example:

• MapIt ID 141651: Glasgow boundary, generations 1-14 GSS code S12000043
• MapIt ID 152275: Glasgow boundary, generations 15-35 GSS code S12000046
• MapIt ID 2579: Glasgow boundary, generations 36-40 GSS code S12000049 [As a reminder, to not break external systems, this ID was kept with an updated boundary rather than this being the gen 1-14 boundary.]
• MapIt IDs 20767-20787: Glasgow wards, generations 8-30, children of 2579
• MapIt IDs 151265-151287: Glasgow wards, generations 31-40, children of 2579

Glasgow had ward boundary changes at generation 31, and small self changes at generations 15 and 36. The authority concept is "Glasgow City Council", and let us assume there is a "South Scotland police area" covering Glasgow, Edinburgh and some other councils.