[EM] Geographical districts

Juho juho4880 at yahoo.co.uk
Thu Sep 4 14:13:13 PDT 2008


I like natural districts, so one approach would be to let people say  
and let history decide. The reason why I find "natural" districts  
natural in politics is that when people feel like they are part of  
some community it is easier to find consensus and cooperate within  
that community. And of course the border lines will then follow  
whatever natural dividing lines there are.

One simple approach would be to ask the voters directly about the  
(physical/mental) distances. The answers could be of e.g.  
Village1>Village2>Village3>... There could be more villages on the  
questionnaire than there will be districts. Also the home coordinates  
of each voter would be known. With these values you can then draw the  
districts so that you serve the voters/inhabitants as well as you can  
an let them belong to the districts that they like (because of  
driving distance or historical or whatever reason).

One could e.g. first pick n random villages as the district centres  
(voters may or may not need to travel there to vote), and then  
optimize the border lines so that more and more people are happier  
and happier with their district, and occasionally change also the  
chosen villages to check if that could lead to better results. Also  
some basic rules needed to keep the districts compact. This is thus a  
general optimization problem (and sufficiently "computationally  
feasible" in line with the theme of this mail stream).

If you have single seat districts you have to force the districts to  
be about equal in size. This will work against having natural border  
lines, but at at least we can force the results to be as natural as  
possible.

There's some risk of someone trying to gerrymander the border lines  
by giving guidance on how to vote. But this may not be a practical  
strategy.

Juho


On Sep 3, 2008, at 22:46 , Jonathan Lundell wrote:

> I haven't been following this thread in great detail, but I do have  
> a question: what is the distance function actually trying to  
> measure and minimize? What exactly are we trying to optimize when  
> we minimize "distance", by whatever measure? I might be close in a  
> crow's-flight sense to a neighbor on the other side of a river or  
> freeway with a driving distance of several miles.
>
> OK, we could solve that in principle (though not too quickly) by  
> using Google Maps driving time, or the like. But what does driving  
> time have to do with grouping voters (unless we're drawing a  
> precinct and measuring travel time t the polling place)? Maybe we  
> mean communication: two people with telephones are closer in this  
> sense than people without (and people with unlimited long distance  
> are close in this sense independent of cartesian distance).
>
> I live in several voting districts where geographical lines make  
> sense--my local fire district is a case in point, as would water  
> and sewerage (except that I provide my own in those cases, as it  
> happens). But legislative districts? I can't think what I'm trying  
> to optimize for which straight-line vs manhattan distance would be  
> relevant. I've never met my representatives on business; I  
> communicate with them via email or telephone, and I neither know  
> nor care where there local offices are.
>
> On Sep 3, 2008, at 12:17 PM, Raph Frank wrote:
>
>> On Wed, Sep 3, 2008 at 1:57 PM, Brian Olson <bql at bolson.org> wrote:
>>> I checked my code and I'm not doing the expensive square root.  
>>> It's not
>>> quite the second though, it's actually:
>>> ((dx*dx + dy*dy) * weight)
>>>
>>> The weight gets nudged by multiplying by 1.01 or 0.99. Squaring  
>>> the weight
>>> or not and how it's nudged is probably just an efficiency issue  
>>> and not a
>>> correctness issue, it should still get to the weight it needs,  
>>> just maybe
>>> along some suboptimal curve.
>>
>> I think it is equivalent anyway.  Well, you might have to multiple by
>> 1.02 and 0.98 instead to get the same as weight squared.
>>
>>> I think multiplicative weight makes more sense. No chance of  
>>> underflow, and
>>> might scale better between districts with different densities.
>>
>> Well, negative distances are fine too :).
>>
>> However, it could mean that the point ends up outside its district.
>>
>>> Yes, the block shape file determines adjacency. They handily  
>>> label every
>>> line segment with what block is on either side of it, so I can  
>>> pretty
>>> quickly filter that to keep a list of all pairings I've seen.
>>
>> Ahh, cool.
>>
>> I might have a look at that file again.  It just seemed more trouble
>> than it was worth.
>>
>> In my software, I just assume that the people are compressed down to
>> the location point given in the block group table.
>>
>>> Of course I do
>>> also wind up going back and rendering that geometry to an actual  
>>> map.
>>
>> So, the maps on your site draw the boundary as it using the
>> block-group boundary info?
>> ----
>> Election-Methods mailing list - see http://electorama.com/em for  
>> list info
>
>
> ----
> Election-Methods mailing list - see http://electorama.com/em for  
> list info


	
	
		
___________________________________________________________ 
All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine 
http://uk.docs.yahoo.com/nowyoucan.html




More information about the Election-Methods mailing list