Spent much of the day today getting parts and replacing our water pump. The old one wasn’t drawing water out of the tank very well, didn’t show pressure on the gauge, and couldn’t be primed without taking it off of the pressure tank. Earlier in the week we had a brief freeze-up of our supply line and I decided it was the last time I was going to drag the old pump off the pressure tank just so I could prime it.
The new pump is a Myers pump, Made in the U.S.A., and seems to be a little quieter than the old one. While I was doing it, I replaced a few more of the plastic compression fittings in the mechanical room with crimp-style fittings. The plastic ones are no longer sold because they eventually leak.
One remaining issue is getting the pressure tank and the pressure switch working well together. When I first hooked it up, I lowered the pressure tank to 18 psi (2 pounds lower than the low setting the switch is supposed to default to), and the pump starting rapidly switching itself on and off again. I tried lowering the pressure in the pressure tank until there was nothing left in it, and then started looking at the new gauge. Turns out the new switch was set to something like 15–30 instead of 20–40. After I filled the pressure tank back to 18 psi and adjusted the pressure switch to 24–35, everything works without the on-off-on-off problems. I’d like it to be closer to 20–40, but that will take some fine tuning of the pressure switch.
I took Friday off from work again this week and brewed Overflow Old Ale. I drained the chilled wort directly onto the yeast cake from last week’s brewing effort, so I should get a nice fast start from the yeast. The recipe was supposed to be a high alcohol (7%) lightly hopped ale, but instead of an expected 70% efficiency at extracting sugars from the grain, I wound up at 57%. That’s the lowest efficiency I’ve ever gotten. I wouldn’t mind so much if they were consistent, but they’re all over the map, and I don’t know what is causing the variation. Same base grains, same procedure and equipment, same thermometer, etc. It’s a mystery.
The good news is that nothing went wrong, and beer is beer regardless of whether it turned into the batch you were planning to brew. I’m sure I’ll enjoy drinking it at least as much as I did brewing it.
The batch is named for the overflow that’s currently moving across the top of the frozen Creek. I took advantage of it and used it in my counterflow chiller to bring the boiling wort down to pitching temperatures in 10–15 minutes. The water is at least a foot deep, and I don’t think it’s been warm enough for it to be a natural phenomenon. Last year’s overflow event was rumored to be a large discharge from the mine several miles upstream from our house, and this event looks similar. Despite providing chiller water, it’s a drag because it’ll take at least a week for it to freeze solid again and until it snows it’ll be treacherous to walk on. I had hoped the overflow would have flooded the DNR pond again, as it was really fun ice skating on it last year, but the floodwaters aren’t high enough to cross onto the pond. The photo at the top is taken where the Creek passes the pond.
The photo on the right shows the Google Maps image of the location I took the photo using the iPhone web app I wrote. This morning I added some code to draw a blueish buffer around the GPS location that’s sized using the reported GPS accuracy. It also scales the map so that the entire property fits on the screen (I zoomed in before taking the photo on the right). I think the app is pretty much finished, except I want to add Fish and Game Management Units to it. Unfortunately, they don’t have GIS files for the smaller Management Areas, so it won’t be as useful as it could be. You can see I’ve drained my battery playing with it!
Now that my two year web hosting contract with BlueHost is coming up, I’ve decided to migrate over to Linode. It’s about twice as expensive, but you get your own Xen virtual machine to do with as you want. With BlueHost I wound up needing to compile a whole bunch of software packages (gnuplot, remind, spatialite, a variety of Python modules, etc.) just to get my site to work. And I couldn’t upgrade PostgreSQL, which left me unable to use PostGIS. With my Linode, I put the latest Ubuntu on it, and was able to install all the software I need.
As mentioned, PostGIS is one of the benefits of this. Instead of loading the Fairbanks North Star Borough tax parcel database into spatialite and using a CGI program to extract data, I’m able to query the same data in PostGIS directly from PHP. That means I can do all sorts of cool stuff with the data I’m extracting.
Here, I am using the Google Maps API to draw the property polygon and put a marker at the location from the iPhone’s GPS. You can see the result on the right, taken while eating lunch at the office. If you’ve got a GPS-enabled smart device and you’re in the Fairbanks North Star Borough, the link is http://swingleydev.com/gis/loc.html.
One enhancement would be to include a circular buffer around the point marker so you could get a sense of where the GPS accuracy places you on the map. This is complicated with Google because of the custom projection they’re using. I think it’s called “Google Mercator,” but spatialreference.org lists several projections that look like they might be compatible. I’ll have to give those projections a try to see if I can make a projected circular buffer that looks like a circle. It would also be nice to set the map extent to match the extent of the parcel you’re inside. I don’t know if that’s part of the Google Maps API or not.
Here’s the code:
I took Friday off from work and brewed my first batch of beer in quite a long time. It’s a brown porter named Crazy Kittens Porter. As should be obvious, it’s named after our three crazy kittens Caslon, Tallys and Jenson, pictured on the right. This time around I developed the recipe using the BrewPal iPhone app, trusting all the measurements and temperatures to the app. We’ll see how well it does. My favorite part of the app is the “style” tab, which shows you what styles your recipe conforms to and to what degree.
Normally I do everything out in the red cabin, but I had the wood stove cranking so I heated the strike and spare water on the wood stove and drained the mash in the kitchen (shown below). It was nice to be able to do that stuff in the house and to avoid burning fossil fuels for the wort production. As usual, I boiled and chilled the wort outside and set the fermenter in the old fridge out in the red cabin. It’s bubbling away now.
I plan to brew another batch of Devil Dog on top of the yeast cake from this batch. This is an excellent way to save some money on yeast, and the second batch normally gets a very explosive start from the massive population of healthy yeast.
Today I went for a walk on the Creek with Nika and Piper and it occurred to me that the iPhone ought to be able to tell me not only where I am (which it does quite well with the Google-driven map application), but on whose property I’m walking through. It took me a little time, but I now have a webapp (http://swingleydev.com/gis/loc.html) that can do this (don't bother clicking on the link unless you're on an iPhone or other GPS-enabled device).
The result is a pair of pages. The first one shows you your current location, speed, and heading. With a press of a button (and a delay while the database finds the property owner) you can see the Borough information on the property you’re currently inside (assuming you’re in the Fairbanks North Star Borough—this page doesn’t do non-Borough residents any good).
Here’s how I set it up:
My web hosting provider doesn’t have a new enough version of PostgreSQL to run PostGIS, which means I need to use the spatially-enabled version of SQLite3, called Spatialite. To get the parcel database from the shapefile to Spatialite requires the following steps. Some parcels are eliminated in this process, but it’s a small fraction of the parcels in the database:
Download the parcels shapefile:
$ wget ftp://co.fairbanks.ak.us/GIS/tax_parcels.zip
Unzip it and insert it into a spatially enabled PostgreSQL database using ogr2ogr. Crash the process immediately:
$ unzip tax_parcels.zip $ ogr2ogr -f "PostgreSQL" -t_srs EPSG:4326 -overwrite -skipfailures PG:"dbname='test'" tax_parcels.shp
Fix the column definitions:
sql> DELETE FROM tax_parcels; sql> ALTER TABLE tax_parcels ALTER COLUMN sqft_calc TYPE numeric (22,12);
Re-import the data:
$ ogr2ogr -f "PostgreSQL" -t_srs EPSG:4326 -append -skipfailures PG:"dbname='test'" tax_parcels.shp
Convert the geometry column to MULTIPOLYGON:
sql> ALTER TABLE tax_parcels DROP CONSTRAINT "enforce_geotype_wkb_geometry"; sql> ALTER TABLE tax_parcels ADD CONSTRAINT "enforce_geotype_wkb_geometry" CHECK (geometrytype(wkb_geometry) = 'MULTIPOLYGON'::text OR wkb_geometry IS NULL OR geometrytype(wkb_geometry) = 'POLYGON'::text); sql> UPDATE tax_parcels SET wkb_geometry = ST_Multi(wkb_geometry); sql> ALTER TABLE tax_parcels DROP CONSTRAINT "enforce_geotype_wkb_geometry"; sql> ALTER TABLE tax_parcels ADD CONSTRAINT "enforce_geotype_wkb_geometry" CHECK (geometrytype(wkb_geometry) = 'MULTIPOLYGON'::text OR wkb_geometry IS NULL); sql> UPDATE geometry_columns SET type='MULTIPOLYGON' WHERE f_table_name='tax_parcels' AND f_geometry_column='wkb_geometry';
Re-import the data (there will be thousands of errors, but this insert should add the MULTIPOLYGON rows that weren’t inserted the first time around):
$ ogr2ogr -f "PostgreSQL" -t_srs EPSG:4326 -append -skipfailures PG:"dbname='test'" tax_parcels.shp
Get rid of the illegal polygons:
sql> DELETE FROM tax_parcels WHERE NOT ST_IsValid(wkb_geometry);
Convert to spatialite:
$ ogr2ogr -f "SQLite" tax_parcels.sqlite PG:"dbname='test'" -dsco SPATIALITE=YES
sqlite> SELECT street_add, owner_firs, owner_last, owner1, owner2, owner3, mail_add, ci_st_zip, round(acres_calc, 1) as acres, ’$’ || total as total, ’$’ || land as land, ’$’ || improvemen as improvements, pan, sub, block, lot, road_water, lot_size, units, neighborho, primary_us, tax_status, tax_year, mill_rate, business, year_built, situs_numb, situs_name FROM tax_parcels WHERE Intersects(GEOMETRY, SetSRID(MakePoint(lon, lat), 4326));
Again, implementing this would be a lot easier if I could install PostGIS on the server and use PHP to access the data directly. Because I can’t, spatialite and CGI do the trick.
Update: I added a few more steps to convert the initially imported POLYGON layers to MULTIPOLYGON, which then allows us to include the MULTIPOLYGON rows from the shapefile.