Add cd:at-large to states with only one congressional district
j-ro opened this issue · 5 comments
This may not be the right place for this discussion, but...
I'd like to propose a different handling for OCD IDs for at-large districts. Currently, it seems there is no OCD ID for an at-large district, rather the next highest OCD ID division is used.
For example, Vermont has only one member of Congress, so his OCD ID is ocd-division/country:us/state:vt
Whereas, in a state with more than one member, they have divisions like this:
ocd-division/country:us/state:nc/cd:2
This makes it hard to regularize data and match between systems. It's easy to match via OCD ID, but in this case, the state level OCD ID is also shared by other elected officials (governors, senators), making matching harder and necessitating special rules for these states.
It would be better if this were handed like the Sunlight API handles them (https://sunlightlabs.github.io/congress/legislators.html), where they assign a district of 0 to at-large districts. So, for Vermont, we'd have ocd-division/country:us/state:vt/cd:0
@j-ro interesting idea
I'm not so much a fan of that syntax (cd:0), but something like state:vt/cd:at-large might be OK. It could be defined as an alias.
I'm torn on this, since they should represent geographical divisions, not political ones necessarily.
How does this make it harder to process? I guess I'm not seeing where this would break stuff, unless you're using the local-part slugs for something (rather then the post.id)
at-large works for my use case, sure
The way I understand it, right now there are a ton of OCD-IDs that represent both political and geographic areas, like ocd-division/country:us/state:nc/cd:2 or ocd-division/country:us/state:nc/sldu:1, etc...
This is pretty much the same -- there's still such thing as Vermont's congressional district, it just happens that this geographic boundary is the same as the state's boundary. That may not always be true, given redistricting, but it is now. So a separate OCD ID I could see as semantically appropriate.
Oh, and on your processing note...
There are effects in other systems where this becomes harder.
For example, Google's Civic API uses ODC IDs. So, if I want to compile a list of all members of congress (which is what we're doing), I send it all the OCD IDs from all congressional districts and it sends me back just the elected officials that match those districts. Except, for at-large districts, I have to send whole states, which means Google gives me back all kinds of elected officials beyond the ones I care about, and I now have to filter carefully, sometimes using natural language.
Basically, it turns all at-large districts into edge cases that have to be handled differently, whereas if this were just another district, I could handle it the same way.
And yes, we are parsing the ID as well, to do matching -- so we know member from district 1 from the sunlight API matches the elected official we get for cd:1, but we can't necessarily say the same for district 0 because many people match to state:vt
state:vt/cd:at-large makes sense to me in terms of having a complete set of congressional districts under the cd type.
However, at the local government level, there can be dozens of at-large councillors, which requires special handling/logic anyway. In that case, I don't see the value in having an at-large alias.