Me too. I love MM and want to continue using it.

Bri

Note: my background isn't in mapping, although I've played with a few mapping file formats a bit my understanding of the maths and even the terminology involved is limited so may not be used quite correctly in the info below...


I think the problem here might just be a limitation of the file format. If you look at the (unofficial) specification for the qct format you can see how the positions are worked out. Pixel position (simple x,y coordinates in the image) are converted to WGS 84 lat/long for GPS use, or back again. This is essentially the same concept as converting between British grid and WGS 84. Doing that sort of conversion isn't simple, it involves lots of maths to convert between a grid and coords and then between different ellipses and such like.

Have a look here for an example of the sort of work required to do a conversion from a grid reference to a lat/lon position (in this case actually British grid to wgs84):
http://www.movable-type.co.uk/scripts/l ... idref.html

Memory map needs to do something similar to convert from a grid position (in this case simple pixel coordinate) to a wgs 84 lat/lon. However, according to the specification, the way it approaches essentially the same problem is with a trivial formula and a set of pre calculated values for the area covered by the map. The specification doesn't explain how to compute these values, but I assume they are some kind of half way step for maths similar to the example above and the calculation is finished off with the simple formula given in the spec. Without knowing the first part of the calculation I can't be sure if it's a good method (like that given above) or if it's a simplification (as I suspect). It appears to me that this approach results in a loss of accuracy compared to the doing the full calculations - the precomputed values are probably approximations, averages across the whole map. This would be fine for a small map, for a larger map it looks like the errors become big enough to be a problem once you stray far enough from the average position. As a single DMS map now covers the entire country the values used to calculate the position are fixed for that huge area rather than for just a small chunk of it (as they were in older separate maps).

Now when you want to work with British grid in memory map it appears to do these conversions with a simple helmert translation, as mentioned previously OSTN02 is a better way to do this but that requires a lot of extra data which I guess then (and possibly still now) memory map don't want to have to ship with the product. This means a map could be out by a few m (in my playing I've seen up to 4m at most) in certain places in the country to start with. This may or may not work in your favour (compounding or compensating for the other error).

I may be way off, this is just a theory based on my limited knowledge. Something to think about though, and it'd be interesting for a developer to comment if this is plausible. Although there seems to be some denial at the moment, which is hard to understand when the problem is so obvious. All you need to do is open the 25k map and hover over the crossing of a few grid lines and see how far off the position is from the nice round number they should be - lines near my home are about 12m off east and 3m north. Oh yeah, and then then trying to suggest your error might be in the data that came for OS themselves, lol.

Great post. Hope it gets picked up on.

It occurs to me that the calibration errors we all see might not necessarily be in the .qct files. The .qct map files might be perfect. Perhaps the observed errors are down to inaccuracies in the 'invisible' reference that the cursor uses for it's readout? It's possible to swap maps freely within Memory Map, the cursor doesn't seem to get it's positional info from the underlying map.

Wherever the errors come from, my own observations are that for the Lake District 1:25k map, the error is fairly consistent across the whole of the National Park.

A single .qct file exists on the Lake District Memory Map DVD. This file could be supplied on DVD slightly shifted to make it more accurate, in effect with the appropriate map datum shift already applied. This would put all the grid line intersections to within a metre or two of where they should be. All the GPS tracklogs I've made so far would line up better with the map and similarly any routes made in Memory Map that I exported to my GPS should line up on the ground better. I doubt I'd have noticed any error if the map was only a metre or two out, my navigation just isn't THAT precise!

I am curious to know how OS master files are checked for accuracy. What reference is more accurate than the OS master files (whatever they are) that Jason refers to?

How accurate should the 25k maps be? I assumed that in this day and age they'd be to within a metre or so. Perhaps they should be a lot better than that even?

Perhaps someone could explain how the cursor information and .qct files relate to each other?
I've no idea...but I assumed the cursor info was provided by a WGS84 or OS grid, perhaps accurately described in the software by a known mathematical function. I guessed that the .qct files were accurate images with a little metadata attached to them which allows them to be accurately registered with that 'invisible' grid.

All very interesting.

Geoff

Unfortunately (?) not. If you have a license for any 25k mapping for the desktop try loading them up there, the cursor is visible and you can easily see just how far off it is (you can then compare that to older small maps to prove it should work).


This is a fairly small map, compared to the whole of GB, so you would expect the error to be much smaller, probably into the tolerable range. When I say 'expect' I mean both compared to previous smaller maps and to what I said above (if that's on the money).


Yes, "don't blame us - maybe OS put the mountain on the wrong grid square" :-) I think you need to regard that suggestion with some derision.


Depends how you measure accuracy. I'll talk here about the alignment of the actual map images to the grid (because that seems to be the problem here, we know that because even the blue grid lines on the map are out of position), not the accuracy of features on the map. OS supply the maps for raster/backdrop mapping in square tiles aligned to the British grid so in terms of that grid they are 100% accurate. If you want to know accuracy for grid to GPS positions that depends how it's converted. OSTN02 converts British grid to ETRS89 (essentially WGS84) with an acurracy of 0.1m. Helmert transformation is described by OS as limited to applications with 5m accuracy. Having tested converting some British grid values to WGS84 via different methods to see which produces the same result as memory map I've concluded that memory map uses a helmert transformation when they convert from OS data to QCT data (and as mentioned before they don't ship the data required to do an OSTN02 conversion back again for displaying British grid, so we already knew it couldn't be that). This would mean 5m accuracy for the maps, assuming everything else is done correctly. I'm still making some assumptions about their data source of course, but I'm fairly sure what package they will have from OS. As I say my background isn't strictly in mapping but I do have some connection, and I'm lucky enough to have access to the entire set of OS raster tiles :-)


I did above, well not in a lot of detail but if you want more look for the unofficial specification. Your cursor position is over a particular pixel. The program contains a formula and the map contains some data which combined with the pixel position is used to calculate the WGS84 position. This is where I think the problem is. The QCT file doesn't contain British grid reference for the 4 corners, if it did and a Helmert transformation was used on that, you could expect 5m accuracy (that means out by 5m at worst, most of the map would be better). The QCT doesn't store British grid though (as it wouldn't work for non-GB maps), it stores some system for calculating a WGS84 position directly and we don't really know how that is done (we only have information on the last bit of the calculation).

My suggestion for fixing the maps would be to extract the map as an image (tools are out there for this) for just the section of the map you have bought (assuming a reasonably small size area). Load the image into memory map (would require the 3rd party import license) and calibrate the corners with WGS84 positions (worked out using OSTN02) and export this as a QCT file. You could then load this on your tablet/phone and have a pretty accurate map. Not actually tried this myself but the logic is sound, might have a go at this later today if I get chance.

Hi,

I see austin has just posted again but I'll leave my "reply" unchanged.

AFAIK the "calibration" is within the .QCT file and MM uses it to correctly overlay the "image" (map) onto the theoretical grid (OSGB, UTM, Lat/Long, etc.). The grid is not directly visble onscreen, but can be "examined" with the cursor, or added to printouts, etc..

Firstly, remember that your computer screen and paper maps are flat but the earth isn't! The mathematics of fitting the Earth's curvature onto flat images is complicated. The pixel size of the images is 5 metres on 50k maps and 2.5 metres on 25k maps, so the "blue lines" can be 5 - 10 metres wide and when you move the cursor it is in 5m steps (or 2 - 3m on 25k maps). Also the map datum can be hard to verify, when was the last time you actually rested your GPS on a known Trig Point to test it? Finally, when results do look correct (e.g. in Google Earth) is it because they're mathematically/theoretically sound, or because somebody has "bodged" them to look correct?

However, as miffin (and several other "serious" users) said above the MM 25k (at least) maps' calibration does have some REAL errors in some regions. I have also recorded tracks/points with my Garmin GPS which do NOT correlate the features "on the ground" with those shown by the MM maps. IMHO a Garmin used properly will give positions accurate to within a few metres. So I can confirm "errors" of almost 20 metres on the 25k maps in some regions such as Scotland.

However, I do not believe that the issue is a fundamental problem with MM because my early 1:50k v5 OS maps ARE accurate to within a few metres in the same regions (and everywhere in the UK AFAIK). It appears that somebody has done something "wrong" (or not done something that they should have done) with the calibration of 25k maps for some time (my 25k "Selections" from some years ago have the errors) and maybe the 2012 50k maps (I believe somebody reported these problems also with the 2012 50k maps, but can anybody absolutely confirm this?).

So, despite my early comments above, I do agree that someone in MM should be looking into what has gone "wrong" with the calibration of the 25k maps.

Cheers, Alan.

Ok, tried it (though with only a very small map) and this works but one thing to note... If you recalibrate with WGS84 values converted from British grid using a Helmert transformation you get the same level of accuracy as you should get with memory map, i.e. 5m accuracy. If you have memory map set to show your position in British grid it converts back from WGS84 using a Helmert transformation so you get nice round numbers displayed for your grid lines. If you calibrate the map using OSTN02 you get a more accurate result (which is obviously better for navigating using GPS) but because memory map still uses a Helmert transformation to calculate back to British grid for display purposes the numbers it shows are off by the error in that transformation (i.e. grid position will appear to be out by up to 5m). So if you want it to look accurate use Helmert transformed values when recalibrating the map, if you want it to actually be accurate use OSTN02. Or just use the offset feature to shift the map for the bit of it you are actually using, it's a lot less effort!


You might be right. However, given the lack of interest (publicly at least) from memory map themselves we are left having to speculate about things we might reasonably understand in principle but are really in the dark about in practice because QCT files aren't an open or fully documented standard. I am enjoying the discussion though.

Out of interest, are the early 50k maps you mention the ones that were split into a dozen or so different maps, or is it a single GB map? If you imagine the worst error seen for a full GB maps is about 20m then splitting the map into even half a dozen parts could very likely reduce the error to "within a few metres" as you consider tolerable. Again, a lot of speculation involved. Wouldn't it be nice for a developer to get involved in this discussion...

Hi austin,

No, not split, it's a 3GB "all GB" 1:50k file, copyright 2005 on a single DVD referenced MMV5/OSL/SE/MB366/CGB1.

Until fairly recently the 25k maps didn't cover the whole GB in a single file so an offset could be used for each region (but multiple regions on my Selections products weren't individually calibrated in production). However, the advent of the DMS/.QC3 file format does permit (or even require) a single map file for all - GB so a fix really is required now.


I suspect that there is only one ..... but he does make very good posts on his "hot" topics.

Cheers, Alan.

Hmm, you may have fatally wounded my theory. Maybe. I wonder how the error compared from the split ones to the single 50k. Of course the 50k covers the same area as 25k but will only have a quarter of the pixels (half the size in each direction), so that difference may contribute something. Oh well, I guess we just have to watch and wait. Hopefully if they find the problem they'll give a technical explanation to satisfy the inquisitive amongst us.

Hi,

Perhaps not. Whilst the 1:50k map does appear to have far better calibration than the 1:25k maps in the areas we've discussed (and have 1:25k maps), I thought it worthwhile to check the calibration at some extremes of my 1:50k map. I simply dropped waypoints (the dot symbol) onto the crossing points of various "blue lines" and noted the actual GRs.

Not surprisingly, the worst error is at the North of the Shetland Isles (HP 61013 19965) which is an error of around 40 metres. Then the Western Isles (NL 54005 82024) with around 25 metres error. Lands End (SW 34005 25993) at the South West is not too bad at less than 10m, but I was rather surprised on the South Eastern Kent coast (TR 41005 69988) with more than 10m error - only 100km from London (which looks spot on).

Cheers, Alan.