Landscapes of Injustice

My next problem with creating the GeoJSON is that I have coords in EPSG 32610, in meters, and I need them in WGS84 for the GeoJSON. This approach will probably work:

npm install proj4

node...

proj4.defs('epsg32610', '+proj=utm +zone=10 +ellps=WGS84 +datum=WGS84 +units=m +no_defs');
proj4.defs('WGS84', "+title=WGS 84 (long/lat) +proj=longlat +ellps=WGS84 +datum=WGS84 +units=degrees");

proj4(proj4('epsg32610'), proj4('WGS84'), [493251.00240006257,5459084.067122783])
[ -123.09280153510765, 49.28447161994075 ]

This converts a single point; I need to figure out how to convert polygons.

• Integrated the new price-per-metre data into the spreadsheet output for stats. Reported to JSR.
• Began work on generating mappable data for titles. TEI files are now generated from the title-based XML view, and these can be converted with the BreezeMap code to GeoJSON. This is working, but in the process I discovered that a set of GeoJSON coordinates (for 121 locations) inadvertently got truncated during the import process, so I'll have to rescue that data.

Ids of property records with truncated coords:

152, 159, 168, 174, 177, 184, 190, 193, 194, 266, 267, 268, 278, 281, 283, 288, 293, 294, 295, 320, 321, 322, 323, 328, 329, 332, 333, 338, 339, 347, 396, 424, 439, 480, 481, 482, 483, 484, 485, 488, 489, 490, 491, 494, 552, 553, 568, 569, 570, 571, 572, 573, 574, 575, 577, 590, 610, 623, 630, 636, 700, 701, 705, 706, 707, 708, 710, 711, 713, 820, 821, 824, 825, 831, 832, 844, 845, 846, 847, 848, 849, 850, 851, 852, 853, 854, 856, 857, 859, 860, 861, 862, 863, 864, 865, 866, 867, 872, 873, 877, 891, 896, 900, 925, 977, 980, 984, 985, 994, 996, 997, 999, 1000, 1004, 1006, 1012, 1013, 1018, 1021, 1024, 1031

After putting the coords and areas into the dbs yesterday, I reworked the XSLT that generates the title-based and lot-based XML views of the data so that they include price-per-square-metre for titles and lots, and also a version of it normalized to 2016 values. There are still lots of unknowns about how we handle this data, especially the edge cases (missing lot info, extinguished lots, etc.), but I'm working this stuff out now with JSR.

I figured out how to use QGIS to generate a GeoJSON file with areas in it, and documented that in the protocol document; then I wrote some JS for nodejs to generate SQL update statements to add that data to the db. I created two new fields in the landscapes_dev (my testing db):

ALTER TABLE `props` ADD `prp_coords` VARCHAR( 256 ) CHARACTER SET utf8 COLLATE utf8_unicode_ci NULL ,
ADD `prp_area` DECIMAL( 8, 2 ) NULL ;

Took backups of the dbs, then merged the new data into it. There are 262/1079 Powell St lots without coords/area, and 56/1120 Maple Ridge.

I'm trying to find a straightforward way to calculate the areas of all the polygons in the lot maps created in QGIS by AC, but so far I haven't got one. Trying with OpenLayers and the GeoJSON output created with ogr2ogr, but for some reason the JS won't read the JSON files.

When CN met with me recently, she left a set of permissions forms which had not been uploaded to the server for me to do that. Today I scanned and uploaded them, and let her know.

She's the new Oral History person. Went through the shambles that is the current collection of ill-assorted and ill-named files on the server; she will take control of them and do some reorganization, de-duping and renaming. Went through the process with FileZilla, although she doesn't yet have a netlink id so she can't do anything for the moment.

I've written three tiny scripts to generate usable data in GML, GeoJSON and KML from the binary ESRI shapefiles created with QGIS, and I've added all those the repo. I've been investigating the simplest way to generate usable area calculations, and it seems to be this:

ogrinfo -dialect SQLite -sql 'SELECT ST_Area(geometry)/10000 FROM Plan47534' Plan47534.shp

INFO: Open of `Plan47534.shp'
      using driver `ESRI Shapefile' successful.

Layer name: SELECT
Geometry: None
Feature Count: 2
Layer SRS WKT:
(unknown)
ST_Area(geometry)/10000: Real (0.0)
OGRFeature(SELECT):0
  ST_Area(geometry)/10000 (Real) = 0.597841877829159

OGRFeature(SELECT):1
  ST_Area(geometry)/10000 (Real) = 0.7206513230636

This should be parsable with XSLT (for instance), so an ant task to generate all these things, and hook them up with their lot ids (in ogr:UID elements in the GML files), then generate a stack of SQL statements to update the databases, would seem to be straightforward, if JSR wants us to go that way tomorrow.

Finished the redraft of the article for submission to another journal, and submitted it.

JAEH reviewers reckon, quite rightly, that my article is DH and not ethnic history, so I'm now rewriting it for another CfP that just came out.