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.