Did more work on util functions for the process but realized that the primary requirement for development is to have more flexible maps that can combine different GeoJSON files together, so I've diverted into some dev work on BreezeMap.
I've created the core set of files required to do the processing, and I've started writing some of the simpler functions we'll need. I have a function test module which I'll use to develop the function library; it's going to be essential to develop and test all the functions individually before we start chaining them together to create the monstrous output files, at which point it will be hard to see the wood for the trees. Found a lot of instances of substantial overlap (14%+) between lots which are supposed to be contiguous, so our threshold will have to be pretty high.
Got some more detail in place today, and I've started a new folder in the trunk called propertyStats, and a build file which will be the basis for the process. I'll start by defining resources, then writing some functions (pinching a bit from previous work) in XSLT. This codebase will be cleaner and better-documented than previous work because JSR would like to publish it in association with the book.
Met with JSR and worked on the plan for the next round of statistical work. I now have a working plan which will involve making use of the overlap data generated during the summer to determine the sequence of titles/lots rather than using the rather flaky sequences put together from title data. I've already processed the CSV overlap data into expanded FODS files, then merged it all into a very simple XML file that can be used in the transformations as required.
Along with documentation of my responses to reviewer comments.
Met with JSR, DBM and CB to discuss possible solutions to calculating the area of lot overlap. We've been hacking at this problem without a solution for some weeks, but it's possible that CB can implement something that will solve it for us.
There's a persistent number of properties without coordinates, and in some cases an entire title has no properties with coordinates (usually where there's only one property on the title). This was generating invalid GeoJSON because it was unable to calculate an initial map view area. I've diagnosed and fixed that bug; the results are now showing up correctly in the Jenkins build products.
Ran the ethnicity process for all the new Kits owners.
Adapted the code originally written to process the XML-from-MySQL to incorporate the more rigorous algorithm we refined when processing the directory material, then processed the remaining Maple Ridge owners to assign ethnicity. Only one marginal case, John William Kobata, who might be Japanese, Polish or Slovakian.
Geo-reffed a couple more lots, this time in Maple Ridge, and in the process wrote new documentation for QGIS 3.0, in as much detail as possible. Then started on the next new plan, but it seems to be located rather in the wrong place, or there's somethingt very odd happening with it; it shows a street which doesn't exist where the plan should cover. Need to check back with the researcher.