Louisiana, their proposal vs mine

An early version of Louisiana Senate Bill 1 (for a special session) has been filed and contains maps for redistricting the Louisiana State Senate.
http://www.legis.state.la.us/billdata/streamdocument.asp?did=733174
(starts with legalese district format, listing county and precinct numbers that make up the district, statistics and maps follow in appendices)

They have much wider tolerances for population difference than I adhere to. The least populous district having 110,475 people and the most with 121,985. A difference of 11,510 people. I can do it in 1,030.


My plan creates 5 majority-black districts. Theirs has 10.
http://bdistricting.com/2010/LA_Senate/
My map:

Their map:

Similarly, SB3 proposes Congressional districts.
http://www.legis.state.la.us/billdata/streamdocument.asp?did=733207
Here they claim a spread from 755,526 to 755,592, only 66 people different. My solver could only get down to 5,465.
One majority-black district with 62%. I only got one district up to 41.8% black and 49.7% white.
Their map:

My map ( http://bdistricting.com/2010/LA_Congress/ ):

the smallest way to store data

is not to store it at all.
A unique id for a US Census block winds up being 15 decimal digits, which fits handily into an 8 byte int.
Actually there are less than 10,000,000 blocks in the US, so that could easily be a 32 bit number.
But if what I really want to do is store a mapping from each block to district number for each block (easily a 1 byte number), the smallest way to store this is just a list of district numbers. Use the Census data file as a canonical ordering of the blocks.
CSV for this becomes 15 decimal digits, comma, one to three decimal digits, newline. 20 bytes vs 1.
For the hundreds of thousands of blocks in Texas, after gzipping the CSV, this is a 2372 KB file. gzipped byte list is 32 KB.
Sadly, a CSV file in a .zip archive seems to be the common interchange format for these things.
At least I get to use my format between my client and my server.