<HTML><BODY>
<div> > On Nov 7, 2006, at 5:48 AM, raphfrk@netscape.net wrote:<br>
><br>
> > From: bolson@bolson.org<br>
> ><br>
> > > Since that grows all the districts in parallel, but approximately<br>
> > doubling districts at each step, at the end<br>
> > > you'll have some districts with about double the population of<br>
> > other districts.<br>
> ><br>
> ><br>
> > Yea, I <span class="correction" id="">sorta</span> said that at the end.<br>
> ><br>
> > I think that breaking the country up into simple blocks could allow<br>
> > similar algorithms though.<br>
><br>
> Such data is available.<br>
> http://ftp2.census.gov/census_2000/datasets/Summary_File_1/<br>
><br>
> For example, California is split up into 533163 little blocks. Only<br>
> about 330,000 of them are actually populated. They cut the map into<br>
> lots of little pieces.<br>
<br>
I had a look at that too, and yeah, they are complex.<br>
<br>
Block groups are a little less complex. However, the sometimes have a<br>
block group contained entirely within another block group as an<br>
island.<br>
<br>
Another issue with blocks, was working out their geographic<br>
information.<br>
<br>
I managed to get both at the block group level, but not at the<br>
block level.<br>
<br>
Are blocks always completely contiguous ?<br>
<br>
In any case, I think the real problem is that they collect <span class="correction" id="">alot</span> of<br>
data which is irrelevant to selecting districts. This is what<br>
makes the file format so complex.<br>
<br>
Also, are blocks actually hard to change ? If the are easy then<br>
by modifying them, you can have some control of the end<br>
districts. However, that would be a hell of <span class="correction" id="">alot</span> less control<br>
than being able to draw the lines any way a person wants.<br>
<br>
What about just splitting the State into grid of 1km by 1km squares<br>
and then allowing the legislature to (once off) move the boundaries<br>
up to 500m in any direction. Also, they wouldn't be allowed<br>
to cause a cross over of the boundaries or change the<br>
connectivity. The end result is a grid that can for almost<br>
all purposes be assumed to be a square grid. This makes<br>
the algorithms easier to get to work, the data easier to understand<br>
and a clear result from the algorithm. They wouldn't have to<br>
deal with floating point <span class="correction" id="">geo</span> data. The districting algorithm<br>
would just assume a square grid and be given the population<br>
per "square".<br>
<br>
In practice, it would probably have to be defined in terms of<br>
<span class="correction" id="">longitude</span> and latitude rather than squares. For example,<br>
the grid lines might be at 0.01 degree intervals running E-W<br>
and N-S. If my calculations are correct, that gives around<br>
1km edges.<br>
<br>
However, some cities have a population density of greater<br>
than 10k per square kilometer.<br>
<br>
It might be worth allowing grid "squares" that have greater<br>
than (100?) people to be further sub-divided. However, they <br>
would be required to maintain proper connectivity. <br>
<br>
It all comes down to how accurate the result needs to be. Also,<br>
even if some boxes have a large population, other smaller <br>
blocks can be used to even things out.<br>
<br>
</div>
<div> </div>
<div style="clear: both;">Raphfrk<br>
--------------------<br>
Interesting site<br>
"what if anyone could modify the laws"<br>
<br>
<span class="correction" id="">www</span>.<span class="correction" id="">wikocracy</span>.<span class="correction" id="">com</span></div>
<!-- end of AOLMsgPart_0_e0d765a2-5255-4089-8927-a212ea35f36e -->
<div class="AOLPromoFooter">
<hr style="margin-top:10px;" />
<a href="http://pr.atwola.com/promoclk/100122638x1081283466x1074645346/aol?redir=http%3A%2F%2Fwww%2Eaim%2Ecom%2Ffun%2Fmail%2F" target="_blank"><b>Check Out the new free AIM(R) Mail</b></a> -- 2 GB of storage and industry-leading spam and email virus protection.<br />
</div>
</BODY></HTML>