Summer is not enough to redistrict

      Summer went by really fast. I was busy enough with other problems. Since my blog doesn’t really have an audience, it is more like a diary to be reread someday.   A relative of mine peeked at it.

         I downloaded census and other data for Arizona. I compiled code I wrote in Fortran.  Sorting latitudes into bins seems to work, and I recommend that approach.

     Everybody insists that districts must be contiguous, but nobody publishes a table of adjacent census blocks.  Creating a table for adjacent census blocks was very time-consuming. I tried to create a table with eight columns. Columns 1 through seven were for data, and column 8 was a pointer to more data in case of more than seven sides to a census block. LOGRECNO could be a four byte integer, whereas the GEOID could not. Each row was for the LOGRECNO of a census block. The data in the row was the LOGRECNO of all adjacent census blocks. After the data, the next column in the row is a zero to signal the end of the data. NANs or undefineds are not allowed in the table.  I expected that few census blocks would have more than seven adjacent neighbors.

      Results were poor.  A few sides seem to have the same census block on both sides.  Also, some census blocks apparently had dozens of adjacent census blocks.  It is easier for me to believe these anomalies are errors in the census data, instead of admitting that these anomalies are due to my buggy code.  It was a stretch to extract the necessary data and trapeze all the way from sides to faces to GEOIDs to LOGRECNOs.  The trapeze apparently dropped some data along the way.   Sandboxwalls juggled the data yet again to match the latitudes and longitudes in the bins before putting the data into an internal eight column array for its use.

      It would have been nice if someone else had published such a table of adjacent census blocks. The GIS companies being well-funded by the politicians have staff available to extract this sort of data for their gerrymanders. I suppose the excuse for nobody publishing such a table is that there aren’t that many people attempting to create software to do automated redistricting. This people, however, needs all the help he can get. 

     In Sandboxwalls, when the district seed balloons into another district balloon, vector forces are created. The vector forces accumulate, but are all released at the same time. Having the release at intervals of population increase seem to work better than having a release caused by various events. It can consume a fair amount of time for the vectors to move the district centers to their new positions and re-create the arrays. Wall height was determined such that the effective eccentricity of district to city to County radius was 1 to 2 to 3. When the sand overflowed a wall, a new radius was created at the point of overflow. I never got a complete result, but did expand far enough that the population difference between all districts was under 1%. Some districts expanded to their maximum radius.  I suspect that was not because the district was hemmed in by other districts, an eventuality for which I was prepared. I am afraid it was because of too many holes in the adjacent census blocks data.   I ran out of time before I had a chance to investigate this.   I never did create a dotCSV file for a 30 district map of Arizona.

      Time to forget about redistricting by computer, and get ready to help put on the upcoming consolidated elections November 8.  After that, well, summer vacation is over, so playtime is over.  Maybe next year if I can afford it.

Post a Comment

Required fields are marked *


%d bloggers like this: