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.
Since the missing plans have now been retrieved from the LTO, I'm now taking AC's role to geo-reference the, I followed her excellent instructions, which unfortunately no longer match the version of QGIS that's current on my machine (I've moved from 2.18 to 3.0), so it took me a long time to figure out exactly what to do. I'll rewrite those instructions as a separate version in the same documentation file for version 3.0 when I've done a couple more. The main thing that took me AGES to realize was that to stop drawing a polygon and finalize it as a feature, you have to right-click. There's no GUI control at all, and no other way to do it as far as I can see.
SR has offered to handle the polygon problem, so I generated for her a GeoJSON file containing all the features from the Maple Ridge db. I now have a library for doing that. KF needed a list of J-C owners and their properties as of 1942-03-04, so I've written and somewhat debugged that library (in XQuery); the results are odd, though, since they show no owners from Steveston or Salt Spring, so there needs to be further investigation there. Finally, one of our collaborators needs a hard copy of MP3 versions of our oral history wav files, so I resurrected my Python script and I'm running it now. It should be done by tonight or tomorrow.
Lots of attempts to use both turf and jsts to find intersection or union of polygons, all failing so far. Very frustrating.
Finally figured out how to get area calculation working for polygons in OpenLayers, and I'll put it in here so I can find it the next time I'm pulling my hair out:
var wgs84Sphere = new ol.Sphere(6378137); var getGeodesicArea = function(polygon) { var geom = (polygon.clone().transform('EPSG:3857', 'EPSG:4326')); var area = Math.abs(wgs84Sphere.geodesicArea(geom.getLinearRing(0).getCoordinates())); return area; };
Pass a polygon geometry to the function and you'll get a value in m2. The magic number used to construct the sphere is the radius of the earth. abs is needed because the result is puzzlingly sometimes negative and sometimes positive; that doesn't seem to depend on the order of the coordinates, since my polygons are all properly wound. I can now go on to calculating intersection areas.
Put a lot of time into figuring out if I could use node and turf to do the lot calculation, but it seems unlikely; the current release of turf lacks the advertised boolean-overlap function as far as I can see, and the turf.area() function gives me very weird results (such as negative numbers). Had a go at using OpenLayers under node, but that's very difficult because of its requirement for a browser window object, document, and so on; so I'm now investigating the use of a hosting browser page, which seems more promising. Lots of work to do, though.
Met with JSR and discussed the situation wrt geo plans and properties. Collected the remaining issues with missing plans and turned them into detailed requests for the NWLTO to go back to original titles and confirm/correct data to find them; sent this to JSR to forward. Also did stats on the problems generated by these issues; the number of affected titles is quite low, but we don't know what the number of affected "chains" is yet, because we don't know how chains should be constructed. However, I did make some progress on this. I've started some XSLT to build a spreadsheet of per-lot value histories per sq metre in 2016 dollars.
The next stage is to figure out how to continue the chain for an extinguished lot. My suggested approach is to analyse the potential overlap of all lots, in order to discover any pairs which overlap by more than 50% of the area of one of them; this should be sufficient to generate a link between them, and then any chain can be continued by following [one of] the lot[s] into which it was [de]composed. I think this can be done in JavaScript using Node and the Turf.js library, specifically turf intersect. I'll need to script and test this, then it'll run for many hours to generate all the required lists.