Colonial Despatches

This lists some of the errors that we have encountered, and their respective solutions!

Upon my morning svn update I received this error:

kim@dandelion:~/Desktop/coldesp_xml/xml$ svn update
svn: warning: cannot set LC_CTYPE locale
svn: warning: environment variable LANG is en_CA
svn: warning: please check that your locale name is correct

SOLUTION: type this into terminal

export LC_ALL=C

Use this to find phrases excluding certain words. For example, if you want to find Hudson's Bay, but without "Company," "House," "Territory," and so on:

• Hudson's Bay (?![Cc]o)(?![Hh]ouse)(?![Tt]er)

This info taken from here: http://www.regular-expressions.info/lookaround.html

Catching up with recent changes -- set my local version of the app to regenerate all the OAI records from the latest XML files while out at the dentist, then copied them down from there, committed them to SVN, and uploaded them into the live app.

Completed the addition of new placenames from 1859, of which, there are 59 additions. Hopefully, Theo and Shaun can get through their respective tasks in time to help to complete them.

Following yesterday's post, I've rewritten the XQuery that handles generating the KML files that are passed to Google Maps, along with tweaks to the XSLT that creates the map links in place data display on the site:

• Both types of location (point and polygon) are now handled by the same getKml.xq file.
• The file builds either a <LinearRing> (for a polygon) or a <Point> (for a point) tag into the KML.
• Points have no "natural" zoom level, so they were zooming right in to street level by default. We first attempted to take care of this by setting an altitude of 20000 metres, but this works only for Google Earth, not Google Maps, so we did some experimentation and came up with a zoom level of 8 as the best overall setting, and we now specify that as part of the GET array in the URL for Google Maps (in the case of a point).
• The content of <place>/<desc> tags is now output as plain text twice in the output KML: once as a <Snippet> element (which means it shows up on the left of the map, next to the placename), and once again as a <description> element (which means it shows up inside the "speech bubble"-style popup when you click on the location's pushpin marker.
• We decided against trying to style the description content or embellish it with links, because that would require a second level of processing (XSLT), slowing down the operation, and because most of the links inside placename entries are internal AJAX calls anyway.

Right now, we're handling the link between the places entries and Google maps in this way:

• If there's a single point (one <geo> element) for the location, we're simply passing the coordinates and a placename to Google Maps, which then displays the point.
• If there are multiple points (a polygon), we pass Google Maps the URL of a pipeline that constructs a KML file, which results in a slightly richer display (but not rich enough).

What we need to do:

• Rewrite the XQuery so that it can distinguish between points and polygons in the source, and in the case of a point, construct a Point element instead of a LinearRing.
• Change the XSLT handling place entries so that the KML option is used in all cases.
• Look at enriching the KML with some extra information, using the description tag or some other mechanism.

The biographies files have been tuned up. And, I have added an 1859 biograpies file to the "Bios" folder. I have yet to add the list of new names from 1859, as I await Theo to finish his additions from 1858, as the names I found in '59 may have occurred fist in '58.

In all the current biography files, I have deleted duplicate entries and formatted correctly several of the entries, and where required, updated the necessary tags in the despatches. Along the way, this process has revealed ways in which we can standardize further the way we handle biography entries. I will post these amended standards on the Guidelines document.

I have completed my file-by-file pass of all the 1859 files, adding place, date, people, vessel, and First Nations tags.

Next, I will add the new-found names, of people places and vessels, to their respective content-files. I predict this to take roughly two days, and then we will require entries to be written for, at least, the place names and vessels.

Retrieved from Urchin.