Map Of London

Fixed an encoding error in Abchurch Street -- a block quotation was encoded with a simple <q> element instead of the <cit>/<quote>/<bibl> structure required to produce a blockquote. Also updated some broken links in the Editorial Style page, caused by changes to the page names of other pages.

Met with PS to look at three mockups, which we're now considering. The tentative plan is to finalize the design within a week, and then PS and I will implement it over the next couple of months.

MS requested that <rs> be functional in the same way that <name> is, in providing a link to a personography entry, so I've added it to the XSLT template that handles <name>.

The only potential side-effect might be this:

When you see the popup for a person, it has a list of all the documents in which that person is mentioned. That's retrieved like this:

 $mentions := 
  if ($person/persName/@type != 'cont') then collection('/db/data/')//TEI[descendant::name[@ref = concat('mol:', $personId)]] else (),

If a person is never tagged with a <name> tag, but only with <rs>, in a particular document, that document would not show up in the list. We believe this will not happen -- for every <rs> that is used, the document will contain a <name> somewhere -- but we should keep an eye on this in case we're wrong.

NP raised the issue of bios which are stubs, arising out of Stow markup, which will not be completed in the near term. We decided to add a boilerplate response to fill the popup that appears when you click on the name; if there is no <note> tag in the <person> tag, the bioNotAvailable boilerplate text will be shown. This is working now, but subject to review by JJ.

I've implemented part of our plans for restricting accessibility to documents based on their revisionDesc/@status value. Documents with these values will show up in search results:

• published
• stub
• empty

Documents with any other status (such as draft) will not be retrieved by the search engine. This does not prevent you from accessing such documents through their @xml:id attributes by predicting the URLs at which they should be found. It also doesn't prevent links to those documents from being created on the site. So the two ways to prevent a document from being accessed by the public, while ensuring that we can look at it on the site if we want to, are:

• set its status to e.g. draft or proofing
• don't link to it from any other page

Of course, if you never upload a document to the database at all, it can never show up.

This is a compromise which allows us to look at new documents the way they will appear on the site, while at the same time ensuring that the public don't stumble onto them by accident. A determined person could find such documents by looking at the page of xml:ids, of course.

The reason I've included "stub" and "empty" in the list of published pages is that it seems odd to search for "Bartholomew" and not find the document for "St. Bartholomew’s Hospital", even though that document might be empty; the empty document does link to the map, and call for contributed content.

I've been investigating the relationship between the "tiles" in the old map interface, on which our locations are currently specified as x-y offsets, and the full-size cleaned-up image which forms the backdrop for the "experimental map" rendering. The news is not good.

As far as I can see, each tile has been transformed slightly differently. The x-axes have been resized with slightly different proportions from the y-axes, and each tile has been slightly rotated, with the exact parameters being different for each tile. What this means is that there is no way to convert the pixel offsets in our location files from their tiles to any kind of referent on a full-size single map; each tile is sized and rotated differently, so the math for each individual place would be idiosyncratic.

In other words, the offsets against those tiles are useless for anything else. But we were intending to throw them away anyway, in the end, so perhaps it's all for the best.

On the other hand, I've also been looking at the SVG which underlies the "experimental" map, and that looks solid and useful. It's based on a PNG graphic of the whole map which is very large (10201 x 4001), and is quite clear. I understand that the stitching on this map is not ideal, so we may want to re-stitch it, but if we do, I think we should be able to re-calculate all the existing paths without too much trouble. Being SVG, it's also relatively easy to convert into something else if necessary. We should also be able to split out the individual layers (churches, streets etc.) into separate SVG files, making it easier to work on each of those layers independently; and we can remove the line styling from those files, and configure that externally. Ultimately, we'll have to decide whether we want to store the path information for each location inside its location file, or store the paths in separate SVG files, with each path tagged with the id of the location (as is the case now, inside the single SVG file).

One way or another, though, someone is going to have to learn to work with Inkscape, as Mel did, to create the paths for all the locations. While they're doing that, they may as well be figuring out the real-world coordinates for the locations on Google Earth, and encoding those in the locations files.

The best approach right now would seem to be this: gather the original images from which DB constructed his experimental map, along with as much information as we can about the original pieces (based on the new CD, as well as other instances KF-M may be able to get pictures of from the UK). Using that information, re-stitch the original images to create an improved rendering of the experimental map version, on the same scale. Then split out the existing separate layers from the SVG file, and attempt to transform their coordinates where we can. Check and fix the results in Inkscape, and then continue adding more locations to each layer file.

I now have a working implementation of a full-map view, based on the existing tiles, but rendering places either as central points or as shapes using Canvas. I now need to add mouseover/link features to the Canvas implementation to get something useful for checking offsets etc., as well as showing more detailed place information.

I've reconfigured the GEXF file generation so that it now only generates a single edge for each pair of locations in the input set, and for weighting, it is set by default to count the number of documents in which both locations appear. This results in a simpler and perhaps more meaningful graph.

Following that, I've started work on map_full.xql, which generates a colour-coded display of a set of locations passed in the GET or POST array, on a full-scale view of all the tiles, laid out in a table. This is a quick-and-dirty way of mapping the results of our network mapping. The initial graphing of the most commonly-mentioned locations in our db resuls in three distinct communities, and I can now map those locations colour-coded by community on the full-scale map.

I'm not generating valid GEXF files which GEPHI can read, and I've been experimenting with visualizations and grouping. I'll document this in more detail when I've figured out which visualizations and parameters give us the most interesting and suggestive results, but for the moment, it looks like Radial Axis Layout, and detecting communities with Statistics/Modularity, then the Partition module , is a usable approach. In the layout window, group by modularity and order by degree.

I now have code which is (in theory) generating a GEXF file with nodes and edges based on the co-occurrence of locations in the data collection, but it's taking hours to run, so I haven't yet managed to complete a successful run and see the resulting data. I've tried to cut down the amount of calculation by limiting the nodes to those which are referred to more than ten times, but it's still taking too long, so I'm trying to debug.