HCMC Blogs

Did the stats again using two years; sysadmin kindly recovered the archived year for me.

Including the use of U202f for the space inside guillemets -- it's small and non-breaking. This fixes wrapping issues. I've also added the final page-numbers to all articles and reviews since it seems unlikely they'll now change. Also wrote a piece for a grant application.

Very helpful meeting at the Land Title Office where we learned about how titles are created, how parcels of land are created and described, and lots more. This causes us to re-think how we want the database to work, so it looks like we'll be redesigning from scratch. This will be good in the long run.

Got ArcGIS Server running in a VM on my machine. It runs in a CentOS guest - had xvfd trouble under Ubuntu.
Had to set up a network node in the UVic nets DB, and change /etc/hosts and /etc/sysconfig/network on the VM.

We now have copies of the server software, the desktop, and the desktop interoperability extension, along with one license for the desktop and one for the server, courtesy of RS, and we're testing installation and connection of them. It's not simple. It'll take a while to figure out the software.

Adapted some table-sorting JS I wrote for MoEML so that it works to enable sorting of faculty and staff profile tables on the History site, pending the possible future arrival of the more sophisticated filter system they've asked for in a ticket. There is apparently a similar system already available that you can invoke by adding the "tablesorter" class to your table, but of course we can do this with automatically-generated tables from the profile-block system, so our custom option is needed in this context, and it will serve as a model for adding JS to other Cascade contexts when custom features are needed.

I've consolidated the latest changes into the live db and tested very briefly. I've also considered, and rejected temporarily, the idea of creating something called a "property" which amalgamates lots which share a title; this could be done automatically at some stage anyway. I've written some simple maintenance scripts, including the one which copies the live database content to the dev db, so I'm now in good shape for dev and testing.

The dates had changed, so I had to redo it. Now ready to go.

Late duty. And everything is urgent and must be done yesterday.

It's increasingly clear that titles-to-lots needs to be a one-to-many relationship; more than six hundred titles have additional lots mentioned in their "Doc lots" field. I've been working on how this might be managed, using the dev version of the new db. I have a script which does a number of things to the db structure:

• Creates a new titles_to_properties table and populates it with records for all the existing title/property one-to-one relationships.
• Adds a new prp_desc field to the props table. This is necessary because it's not practical to use the props_abbr view in a one-to-many relationship; instead, we can dispense with that view and replace it with a description field.
• Populates the new field with existing data calculated from the block and lot fields (this may have to be more detailed, using other fields, since we'll actually be looking at non-Vancouver properties down the line, but it's easy to expand it).
• Adds triggers to update and insert which calculate this field before updating or inserting.

I've also updated the local_classes.php file to take account of this. Quick testing suggests this is working well (haven't tried an insert yet, though).

Once this is working in the live db, someone will have to go through and update all those hundreds of existing records, which will be very time-consuming. In most cases, new property items will have to be added to the props table.