Week Beginning 2nd March 2020

This was another strike week, and I only worked on Friday.  Next week will be a full five-day strike.  On Friday I caught up with a few emails about future projects from Paul Malgrati and Sourit Bhattacharya, read through some of the documentation for the SCOSYA follow-on funding proposal that is currently in development and had a further email conversation with Heather Pagan regarding the redevelopment of the Anglo-Norman Dictionary.  Other than that I focussed on the interactive map for Gerry McKeever’s Regional Romanticism project.  Last week I’d imported the new data and made a number of changes to the map, but had discovered that the plugin I was using to give nice Bezier curve lines between markers was not scaling well, and was making the map unusably slow.  This week I experimented a bit more with the plugin, trying to find a more efficient means of making the lines appear, but although the alternative I came up with was slightly less inefficient it was still pretty much unusable.  I therefore began looking into alternative libraries.  There is another called leaflet.curve (https://github.com/elfalem/Leaflet.curve) that is looking promising, but the only downside is you need to specify a latitude and longitude for the midpoint of the curve in addition to the start and end points.  I didn’t want to do this for all 80-odd locations without seeing if the result would be usable so instead I created a test map that uses the same midpoint for all lines, which you can view below:

Even with all of the lines displayed the map loads without any noticeable lag, so I’d say this is looking promising.  After doing this I looked at the first plugin I’d used again and realised that it included a function that automatically calculates the latitude and longitude of the midpoint of a curve between two lat/lon pairings that are passed to it.  I wondered whether I could just rip this function out of the first plugin and incorporate it into the second to avoid having to manually work out where the midpoint of each line should go.  I wasn’t sure if this would work but it looks like it has, as you can see here:

This second map does seem to have the occasional performance issues and I’ll need to test it out more fully, but it is a considerable improvement on the original map.  If it does prove to be too laggy once I update the actual interface I can still use the function to output the midpoint values and save them as static lat/lon values.  I’m still going to have to change quite a bit of the map code to replace the first plugin with this new version, and I didn’t have time to do so this week, but I’d say things are looking very promising.