Map Of London

Figured out a polynomial to make the lines scale intuitively (oddly enough they need to start thick, get thinner, then get thicker again as you go from zoomed right out to zoomed right in). I have colours working for feature categories (although the actual colours will almost inevitably get changed). Still haven't worked on point display yet. I've also figured out how to detect the features under a click, so it'll be easy to decide which one deserves the click based on the extent and type of their geometry. Coming along nicely.

I've written the math bits to convert SVG coords to feature geometry arrays, and it's working for MultiLineStrings and for Polygons; it appears to be fine for Points, but the one Point example I have isn't displaying yet. I have places appearing and disappearing based on clicks in the GUI, and I've got one block of sample code working to change the thickness of strokes based on the resolution.

If I can solve the point problem, then deal with the issue of multiple features for a single location (which is a question of creating an array of Features, and then testing the typeof the FeaturePtr to see if it's an Array or not before doing anything with it), I should be able to start working on a more principled and well-organized version in which we allow for different colours for different categories, etc. And I can also start working on detecting clicks and showing popups.

Making good use of console.log and the Firebug console; that really helps a lot.

Loading speed was very slow because the JSON for locations took time to generate, so I've moved that process offline; it now runs as part of the utilities/createGazetteer.xsl file, and generates two new JSON files (one for categories, one for locations) in the db/generated folder. That speeds everything up.

I now have the GUI for locations and categories working as I want it to, so that checking and unchecking both categories and locations is coordinated and shows the proper state to the user. Next step is converting coords to proper feature coords for OpenLayers.

Following some work and discussion over the weekend, I've added Wiggins, DEEP and DOI to the @type attribute for <idno>; changed mdtEncyclopediaLocationGeneric to mdtEncyclopediaGeneric; changed the <catRef>s of two documents that were in this category; regenerated the schema; and updated the data on the live site.

I now have an object populated by categories and locations, and a page controller which shows the categories. Lots of work going into figuring out how to do what when; sequence is important when we're constructing lots of objects from asynchronous AJAX calls. Discovering differences between FF and Chrome which necessitate changes to the sequences. One emerging temptation is to pre-generate all the AJAX for the entire set of stuff and store it in eXist, then load it as a single object; that would be fastish, but possibly not responsive enough, in that you couldn't selectively load things that people have asked for. Next step is listing all the locations under their categories, then it's on to creating features on the map.

Ported the OL3 example into the dev tree in the MoEML app, and got it working (but using tiles from nfs at the moment, to keep pressure off the web app); finished all the basic JSON/AJAX stuff on the eXist side, and started building the object which is going to handle all the data on the client.

I'm writing the XQuery that generates JSON info for OpenLayers. I've discovered a number of things about the SVG that we should be aware of:

• We definitely want the plain SVG output.
• Paths in the @d attribute begin with m (move to) and if they end with z, it means they're closed paths; otherwise they're open.
• Single points are difficult to represent. If you choose the pencil and Control+left click in Inkscape, you get a point, but it's actually a move-to followed by an elliptic arc (a) command, then its parameters. We can simply get the move-to and deduce from the "a" that we have a point, then represent it as a point feature.
• The coordinates in @d are relative to the first move-to point, so to expand them, I have to calculate each point based on the last one. Also, the y coords have to be minused for OpenLayers.

Ported the code for the new XML output formats to the live site; in the process, I noticed more contexts in which it should not appear (mdt list pages, for instance), so added a trap that only shows it if there is a real XML source document; and I added a page documenting the formats, and linked that from the bottom of the menu. I think this is finished now.

Note to self: the CSS and JS that handles those three buttons (Page Contents, Credits and See XML) is pointlessly repetitive and could be streamlined easily.

The proliferation of XML formats I want to offer from the site has made the current list and its location in More Info a bit ungainly, especially in tablet mode. I've coded up a test view in dev with the XML menu promoted to be one of the main items in the set, to see if that's a solution that the team can live with.

It looks like it's going to be most effective to create our locations as features on layers, rather than to push complete SVG layers out onto the map directly. I've been playing around with creating features this morning using pixel-based polygons, and it works well. I've also begun designing the API. The simplest approach would seem to be to provide the data in JSON, but with embedded HTML for the abstracts. Note this page for tips on escaping. The JSON can be used to construct and populate a large data structure from which features can be shown and hidden on the map, and popups can be populated as appropriate.