Area class feedback

[jpmckinney]

New classes and properties?

• Area
  • creation date: prov:generatedAtTime
  • valid from: the date from which the area is in effect
  • abolishment date: prov:invalidatedAtTime
  • was generated by: the delimitation that created the area
  • was invalidated by: the delimitation that abolished the area
• Geometry
  • approval date: prov:generatedAtTime
  • valid from: the date from which the geometry is in effect
  • valid until: prov:invalidatedAtTime
  • was generated by: the delimitation that created the geometry
  • was invalidated by: the delimitation that invalidated the geometry
  • bounding box: osgeom:extent, ext (ISO 19115)
• Delimitation (a prov:Activity)
  • name
  • generated: list of resources that the activity generated
  • invalidated: list of resources that the activity invalidated

Notes

• Delimitation, e.g. "Canadian federal electoral redistribution, 2012": In Canada, a redistribution establishes, abolishes or changes federal electoral districts (Areas).
• The date on which Geometries are redrawn is not the date on which the Geometries come into effect (for example, at the next election).

If you want to get the geometries of all Boston wards on June 1, 2010, I figure a system should join the areas and geometries tables, filter areas by parent area and classification, and filter geometries by date. If you want to get the geometry of Boston Ward 1 on June 1, 2010, you filter the geometries table by date and by area_id.

[jamesturk]

In general I'm +1 on all of this, but it does have a problem that we have in our own use and I'm not sure there's a great solution to. 'valid' is a complicated concept, there's the time that a district is approved, the time that it is first used in an election, and the time that people are actually serving from within it. Those are 3 separate times (and the rules for them can be incredibly complicated, where portions of a delimitation are put in place while others are held back).

I don't know if you want to address that or not, maybe it can simply be said to be out of scope?

[jpmckinney]

I think this is handled above. The area's creation date and the geometry's approval date are the first possible date for each. Their "valid from" date is the date from which they are first used (in an election). The time that people serve in an area is out of scope for Area, since it's already covered by Membership. Are there any issues with that model?

I expect that most implementations will ignore creation date/approval date. Do you use those dates?

[jamesturk]

I'm not clear how this case is handled:

• a redistricting (A) goes into effect (for elections) on Jan 1 2010
• Amy is elected on Jan 2nd 2010 from District 1
• Bob is elected on Jan 2nd 2010 from District 2
• a redistricting (B) goes into effect (for elections) on Jan 1 2012

On Jan 2 2012, if a user looks up what district they are in & gets District 2 they'd then look at who is tied to District 1 and gets Bob, prior to redistricting they were in District 1, so their rep is actually Amy. The district is indeed in effect, but is not yet in effect for purposes of representation.
(edit: fixed typo)

Because there's a link between Membership-Area and not Membership-Boundary it is ambiguous I'd think.

[jpmckinney]

Ok, so we're talking about dates on geometries. Unless the legislature is dissolved on Jan 1 2012, that districting is not in effect or in force as of that date. It is merely approved for the next election as of that date. So, Jan 1 2012 would go into "approval date", and the "valid from" date would be the date from which the district is meaningful for purposes of representation.

So, in the use case, a lat/lng is submitted to a boundary service, that looks up geometries containing that point, whose valid_until is null or greater than today, and whose valid_from is earlier than today. It ignores approval date. It then walks up to the area of that division, then walks across to the membership associated with that area whose start_date and end_date similarly surround today's date.

Does that work?

"valid from" is a confusing term, which I chose to be consistent with other classes. I think a fair bit of text will have to explain the terms in the documentation, whichever terms we end up choosing. Different jurisdictions probably use "in force" and "in effect" to mean different things. In Canada, a geometry is not "in force" until it is relevant for representation, which is when a legislature is dissolved.

[akuckartz]

I would like to see a bounding box property. This is based on a current diccussion in OParl/spec#258 (German).

This data can be used by a server to inform a client about the relevant part of a map. The bounding box rectangle usually would not be displayed by the client.

[jpmckinney]

Thanks, I've added it to the issue description.

[tmtmtmtm]

👍 for dates on Areas. Without these, constituency changes over time can only really be tracked by inference from Posts or Memberships. This would be much better as a direct query on the Areas themselves.

[LegoStormtroopr]

Going back to the comment on Jun 19, 2014 is how we are approaching it, by keeping the actual geometries and the abstract 'Area' separate.

For example, we have (popolo properties in bold):

• 'Member for Spencer' - an elected Post in the electorate of Spencer
• 'Electorate of Spencer' - an electorate, representing an Area, which may have been redistributed over time.
• then multiple Geometries with timestamps representing when that Geometry was valid.

Adding times and enforcing a single geometry for an area means that at redistribution (which is quite common) a representative may hold the same Post of the same electorate, but require a new area.

[jpmckinney]

Thanks, @LegoStormtroopr !

[kaerumy]

Can we have alternate names? Sometimes there is misspelling in original source, such as elections commission which then gets duplicated downstream.

Common in Malaysia for area name:
Baharu, Bharu, Baru.

The latter being the modern way, but older towns using old spellings and sometimes they use new or old spellings wrongly by mistake.

[jpmckinney]

Hi @kaerumy, yes, I think for consistency this will likely be implemented using the same other_names as for Organization, so you can do that in the meantime.