I've been getting into maps, geodesy, GPS, combined with MapPoint, ASPX and COM. 

Web Calculators

OSGB to Lat Long

Lat Long to OSGB


I'm experimenting with MapPoint 2002 and a GARMIN GPS.

MapPoint 2002 is "pretty cool", but does have a few bugs:

The OSGB inaccuracies are explained below. I have a ActiveX /OCX/ COM component that will correctly *  convert OSGB grid positions to Lat Long for use with MapPoint.

OSGB grid references can only be used with the MapPoint automation interface if your are importing or linking to external data. The OSGB points obtained from the external data are inaccurate.

I do not know of any automation interfaces that take OSGB grid references as direct parameters. More here.

My MFC embedded control solution is here

GPS Downloader

Here's a quick application I've evolved.

Radio Plot

Another quick app, with source, that plots push pins.

MapPoint 2002

As well as the OSGB bugs mentioned above, I'll note a couple of problems:


Try embedding it as a control with in a MFC VC++ application! Yes it works with VB, Word, Excel, but try a proper programming environment! It doesn't work!

It blows up at the assert in the MFC occcont.cpp:

void COleControlContainer::OnUIActivate(COleControlSite* pSite)
    if (m_pSiteUIActive != NULL)

    ASSERT(m_pSiteUIActive == NULL);
// did control call OnUIDeactivate?
    m_pSiteUIActive = pSite;

I ended up with this working solution.

Accuracy with OSGB grid references

MapPoint has got the OSGB coordinate system wrong.

[Update August 2003: The new version of MapPoint 2004 has been fixed!
But the maps aren't up to date. The roads in Monkston were completed in the summer of 2002, not as shown.]

A bold statement. What do I mean?

The Earth is not a sphere. To cope with the irregular shape, our national maps use a coordinate system that best fits Britain only (Airy 1830). GPS and MapPoint uses the "World Geodetic System 1984" (WGS84).

When MapPoint reads in our "quaint, little Old England" map references, it uses the WGS84 coordinate system without transforming to the Airy 1830 "distortion". 

This is explained in "A guide to coordinate systems in Great Britain". Published by the Ordnance Survey. It's a very readable document. (I've given up linking to it: the OS web site appears to randomise its structure at irregular intervals!)

  The National GPS Network web site


I live in Milton Keynes, a new town within the UK famous for its roundabouts. I'll use one as a target for a specific grid reference. On Ordnance Survey pathfinder map 1047 I can see a particular roundabout that lies on a grid line!

As an aside...

If you live in the estate to the north you probably can't get broadband.

Residents there are not connected to the telephone exchange near the 1cm mark on the ruler but connected to one miles away.

That's another story!

Reading off the gridlines I get SP 84000 35550.

I enter this coordinate into MapPoint:

The "Push Pin" is out by 120 metres or so. [See the fixed MapPoint 2004 version.]

I take my Etrex GPS for a spin around the roundabout:

The track, shown by red push pins, is also displaced.

If WGS84 is used, in place of OSGB36, I get the following:

The turquoise pins show an accurate track. (This is done by disabling the Helmert transformation in the Garmin downloader. The generated grid references are wrong - but agree with MapPoint 2002.)

Conclusion, OSGB grid reference works, but use the WGS84 datum! This is not really usable - all OSGB grid references uses the OSGB 1936 coordinate system based on the Airy 1830 Ellipsoid. Only by generating inaccurate OSGB grid references using the incorrect coordinate system can MapPoint be used.

Ignoring OSGB, and using lat. long. MapPoint works fine.

Grid Inquest

A utility is available from Quest. I'll use it on that wretched roundabout:


Lat 52.012042589530
Long -0.777487192828

Grid Inquest performs the Helmert Transform to within 20cm.

Enter the lat long into MapPoint and it's fine! 

This also confirms that I can read an OSGB grid reference from a map!

MapPoint needs that WGS84 to OSGB/ODN Helmert transformation!

Parsing error in TL square

The import data wizard doesn't like Cambridge, but is happy with Milton Keynes.

This CSV record is OK:


but this isn't:

10:40:47,TL4705060256. It ignores the TL.

Reducing to 10 metre accuracy and the wizard's happy:



I will use OSGB grid references, not Lat Long! I have something to get round this limitation.

I guess Microsoft, being Americans, may wonder why this is a big deal. In the UK, our national maps are based on the OSGB grid system. At school we're taught how to read a map using the OSGB grid system. Walkers and hikers use OSGB grid system. It's what we Brits know!


Have I got something wrong? Contact me.

Yes, I'm into the degree confluence project having conquered 52N 0.

Here are some comments from the microsoft.public.mappoint newsgroup.

Someone else noticed!

[August 2003: The new version of MapPoint 2004 has been fixed! Thanks Stephen!]