Map Of London

Places with no Agas Map link were not showing any other geo or linked-data information. I've now uncoupled the rendering of those discrete sets of data in general.xsl.

Playing around with a test phone app at home, I'm working with the gazetteer data and I think it would be useful (for many other reasons too) to make gazetteer data available in JSON format, so I've added that output to the utility XSLT that generates the regular xml version and added the result to the repo and to eXist.

Fixed a typo that cause a missing caption in the gazetteer, and also moved the rendering rules for Stow from dev to live, so that we can prevent inadvertent rendering of the entire book. dev and live should now be in sync exactly, which is nice.

Where an Anno Mundi date was supplied with a Julian equivalent using custom attributes, the rendering treated it as though it were Julian, which was confusing. For now, I've just trapped for this and I show a message saying that it's Anno Mundi. Later we may allow additional processing to insert info about the Julian equivalent, and its Gregorian equivalent.

Implemented today on dev, then ported to live after testing:

• Multiple <location> elements are now supported in <place> elements in our locations documents. Example: ABCH1 has two <location> elements, one with modern Google-Map location data and one with a single point location attested by LAARC.
• Multiple <geo> elements are now supported in a single location. Example: the modern location in ABCH1 has two <geo> elements, because it's actually discontinuous (there's a jog where it encounters King William Street).
• Sources using @source are now supported on <location> elements. Examples: in ABCH1, both <location> elements have @source. The modern location has a pointer to mol:GOOG1, which is Google Earth in our bibliography, and the second has two sources in the attribute, one local bibl reference for LAARC, and one full URL to a specific record in LAARC. All sources are turned into links in the placemark description (so they are clickable in the popups on Google Maps).
• Points are now supported in addition to lines and polygons. Points are implemented such that they're marked with our MoEML rose icon. Example: ABCH1's second location is a single point.
• Abstracts are now rendered into the KML, so if there's an <abstract> in the location file, its text is presented as the initial description in Google Maps.

One additional fix to existing functionality: when a location is linked to a popup (because it has an abstract), the abstract is rendered followed by a "Read more" link pointing to the full page.

Project meeting determined some approaches to researching and encoding GIS location information. Basically, we'll be creating a separate location element for each attested point, path or polygon we discover from our research, and each location element can carry @source, @resp, and dating elements, so we can distinguish the modern locations of places from the historical outlines we may discover from the various sources we have. JT and JJ are working on this now. Meanwhile, I rebuilt the gazetteer and did some tweaks to menus and taxonomies as part of the publication of the gazetteer functionality for the first time.

Added some constraints to prevent retrieval of large numbers of potentially large elements. There is now a list of element names you can customize in the configuration which will only be returned one at a time.

Fixed a bug in rendering of elements resulting in quoted output, relating to the rendering of following punctuation inside the quote marks. This is famously gnarly, but what we have now seems to be working. I also noticed that the habit of leaving spaces at the beginnings and endings of title elements tends to cause rendering issues which we could work around, but only at the expense of yet more finely-targetted XSLT templates and yet more processing time; so I've added a Schematron rule that prevents this problem, and fixed a few dozen instances of it in the collection.

The gazetteer is generated using XSLT in the utilities folder, and in the process it scans the whole data collection. Running it to update the gazetteer page today threw up multiple problems with three XML files, so I've fixed those.

Meeting today with KMF, JJ and SM about regnal dates. These are conclusions:

• We need to split Julian dates into three kinds: julianmarch (Stow's version of Julian, with the year beginning March 25), julianjan (Cheney's version, which Holinshed also seems to prefer, with the year beginning on Jan 1 (Cheney) or at "Christmas" (Holinshed -- I think we can use Jan 1 for this too), and juliannotsure, for dates where the beginning of the year is not clear.
• We need processing for Gregorian versions of all three (with the last being a combination of the two others).
• Stow Julian dates need to be switched to julianmarch.
• Other Julian dates need to be assigned to one of the three, depending on evidence.
• SM's excellent spreadsheet on regnal dates needs to be turned into a set of nested tables, with reigns containing tables of years, each year being a row with a unique id (william_1.3 for the third year of William I's reign), and each date for the beginning or end of a year being a date element tagged with the appropriate type of Julian value. This needs to be rendered into a handy reference page.
• Tagged regnal dates in Stow and elsewhere need to be linked to the appropriate row in the regnal date table using the -custom attributes.
• Rendering code needs to be written for the regnal custom attributes so that there's a useful mouseover popup, and clicking on them actually retrieves the relevant row of the regnal dates table as a popup with full info.