Allow positions to be associated with an area

[evdb]

A position should be able to refer to an area. For example some one might be a 'representative' of a certain constituency.

It would be nice if the area could be stored as a string, in which case it is just the name of the area.

Or it could be a url, in which case it is assumed that this url refers to an area stored in a MapIt instance.

When entering the area we should use a select2 style input that searches the MapIt instance for the name being entered and allows the user to select a result. When selected the MapIt url is stored. If no suitable match is found then a plain string of the name is stored instead. This allows the data to be entered and a later task could be to create a suitable entry in mapit and then associate the position with it.

When displaying the position the code would need to fetch (and probably cache) the relevant details from MapIt. It seems reasonable that no-one is going to give some place a name that starts with http://...

[evdb]

As well as matching the place to areas in something like MapIt we might want to match them to places (ie points) in GeoNames

[jpmckinney]

I assume the position should link to an area in a specific generation in MapIt?

[mhl]

@jpmckinney: an area in MapIt already defines the range of generations in which it exists, so I don't think we need to explicitly specify a generation as well the area ID in a particular MapIt instance. (Or have I misunderstood what you're saying?)

[jpmckinney]

I think I misunderstood something about MapIt. What happens when an area's geometry changes due to a redistribution/redistricting? Is a new area created or is the old area updated? If it's an update, how are versions of that area managed?

[mhl]

@jpmckinney: It depends to some extent on the policy chosen for the particular MapIt instance. For example, with the UK MapIt, when the Ordnance Survey release a new release of a dataset they are generally good about creating a new ID for an area if there are legislative changes to a boundary, but keeping their ID the same if it's just a correction to the existing boundary. So, with MapIt UK, we only create a new area if the OS have changed their ID, and otherwise replace the geometries associated with existing area - the old geometries are lost in that case. (There's a new generation for each of their releases: if there's no new area, generation_high in the existing one is raised; if there's a new area created, it has generation_high and generation_low set to the new generation.)

In contrast, when there's a new release of MapIt Global, we always create a new area unless the OSM relation / way ID matches and the polygons are exactly the same as on the previous import. (There's a new generation for every quarterly import.)

[jpmckinney]

OK, so to avoid boundaries being lost, you need to create a new area, even if it's in some respects the same area as an old area.

What happens if an area changes names? I know in TheyWorkForYou, mySociety is very careful to not call a speaker "Sir" when displaying a 2008 speech in the House of Commons if they were only knighted in 2010. Is there anything in MapIt to ensure that you continue to call a constituency "Foo" while in a past context, and only "Bar" after the date at which it was renamed "Bar"?

[dracos]

"very careful" <-- theoretically, you are right, but I think you may be assuming greater carefulness on our part than actually exists :-) The TheyWorkForYou model for doing this is not great, as it involves creating a whole new instance in the member table for any such name change (better would be date-ranged names within a member, as popit does).

If a constituency changed name in the UK, it would be part of a boundary change of e.g. all the English constituencies, and so would be entered in a new generation in MapIt. Constituencies in TheyWorkForYou are just strings, so old constituencies are always displayed appropriately in past context, but that's due to historicalness, if they were linked with mapit IDs, that would continue to work.

[jpmckinney]

It just occurred to me that if PopIt wants to be a true component and not a "mySociety component", then PopIt should not make many assumptions about what boundary component is being used. It should be possible to use PopIt with represent-boundaries, for example, used by the Sunlight Foundation, GovTrack, and Open North.

[evdb]

After discussing in a group a way forward appears to be to represent a place in PopIt as just a name and a uri. This allows places to be created for a position (membership/role) for basic users, and for more advanced ones the uri to the external store can be used for things like boundaries etc.

The admin interface can present this cleanly to the user with the normal find or create semantics.

[jpmckinney]

So something like this?

{
  "@type": "Post",
  "label": "Member of Parliament for Avalon",
  "role": "Member of Parliament",
  "area": {
    "id": "http://example.com/areas/foo",
    "name": "Avalon"
  }
}