A vexed question this one, and one I think I've discussed about 50 times before, to no definate conclusion.

To my mind there are two different classes of grid reference: The low res ones (100km, 10km, Tetrad and maybe 1km) clearly refer to the grid square of appropriate size immediately to the northeast of the point specified (e.g. SU06 is the square with SU000600 at it's southwest corner). In such a case you might argue that the eastings and northings of the point at the centre of the square are as good as any other to define the location (that is to say they are effectively the average of all possible eastings and northings within that square).

For higher resolutions though (maybe 1km, definitely 100m, 10m, 1m)  treating the squares in this way seems to me to be wrong. If a grid ref is chosen by picking the closest point on a map, I would argue that the grid reference defines the centre point of the square, not the southwest corner. The only exception to that would be a reference derived from a gps reading which has been truncated (rather than rounded to the nearest value).

I guess what I'm sayin Graham, is you are right, and wrong as well, depending on the resolution of the record and how the reference was derived. Personally I don't even look at the eastings and northings in recorder, if I need them I will make my own.

You could always create your own e & n attributes in the report_field and report_attribute tables, if you can work out how (it isn't that hard if you look closely at other items in those tables, and there there is some help on the wiki)

The thing with OS grid references is that they don't reference a point; they reference an area. A grid reference, technically, is neither referring to the SW corner of the square nor the centroid, but the whole area. So the most accurate way to plot grid references is to draw squares rather than plot points, otherwise the representation is going to be flawed, depending on the scale the data are viewed at. I know Recorder can output squares directly, which is sometimes handy.

I agree that below a certain threshold it is often better to display a dot, but that threshold is relative. If you're zoomed right in, then a 1KM grid ref plotted as a dot is going to be very misleading whether it is plotted at the centre or the SW corner.

Even if you have a 6 figure reference (two letters and 6 digits - 100m), then that is still quite inaccurate. If you take SU935739 for instance:

http://homepage.ntlworld.com/keith.balmer/BNHS/focuson/getagridref/html/index.htm?gr=SU9355073950&zoom=17&maptype=Sat&en10000=false&en2000=false&en1000=false&en100=true&en10=true&enwgs84=false&enVC=false&enCounty=false&enAWS=false

An observation made at that reference is very unlikely to actually be precisely on the SW corner - but it is going to be somewhere within that square, so, as Rob suggests, moving the dot to the middle of the square is probably going to make it more accurate, on average (the centroid being the shortest distance to any point in the square).

Zooming down further, when you're at 10m level, moving from the SW to the centroid is a move of just 5m which, in practical terms, is not going to cause many problems unless in exceptional circumstances, surely? So perhaps it is only when you get into the 10m arena one can plot a dot with any degree of practical confidence?

We actually have both standard (SW corner) and centred eastings and northings attributes in our Report Wizard. I believe they originally came from Mike Weideli. Another technique I've used is to output squares as a shp file from Recorder, then convert them to points in GIS. But a bug in the shp output routine seems to make it choke on 14 figure (!!) references. Which reminds me I must post a report of that bug.

Here's a screenshot of squares exported from Recorder, then symbolised with colours using the Spatial Precision attribute (again, from Recorder):

http://i.imgur.com/Oy04g.jpg

Note how the 100m squares (8 character references) appear as dots anyway. Here's the same data plotted as points:

http://i.imgur.com/BSzcg.jpg

It gives a totally different feel to the data, almost conveying a very different message. In this case, the sweet spot for accurate general representation is probably a combination of dots and squares:

http://i.imgur.com/rIjqo.jpg

Charles

I have checked the UDF's [dbo].[LCReturnEastingsV2]  and [dbo].[LCReturnNorthingsV2] and the parameter is appears to be working correctly. If you are using XML reports which contain these functions then to get the SW corner of the square  change the last parameter to a 0 and it should work.

select distinct [dbo].[LCReturnEastingsV2] ('SU7090', 'OSGB',0 )  returns the SW corner 
select distinct [dbo].[LCReturnEastingsV2] ('SU7090', 'OSGB',1 )  returns the centre.

select distinct [dbo].[LCReturnNorthingssV2] ('SU7090', 'OSGB',0 )  returns the SW corner 
select distinct [dbo].[LCReturnNorthingsV2] ('SU7090', 'OSGB',1 )  returns the centre.

Hi David,

Either from the map - Map -> Export Distribution Points from the menu, or from a report results grid, click Report Output -> Export to ESRI Shape File...

Coming back on these other points, actually I think this is actually one thing which Recorder has got reasonably correct. Firstly, it stores the original entered grid reference or GPS coordinate in the database at all times, so you never lose any precision on the underlying data due to some assumption. Then, as Mike pointed out the conversion of these to Easting and Northing is purely a reporting task handled by his 2 user defined functions in the database. And these are parameterised to allow you to choose to return either the centre of the square or the bottom left corner.

In actual fact, if the underlying data is just a grid square above 1 metre precision there is an argument to say that you should not be allowed to view this data as an easting/northing, because the SW corner and centre point both infer an accuracy on the data that is not there, and in most cases both will be wrong. That's why Recorder's own mapping screen would actually drop out any references that are not precise enough to draw at the requested resolution, and why the default behaviour now is to draw the original square not a point.

Best Wishes

Hi
Thanks John.
I've used an xml report to pull out the fields I'm interested but when I click on the report output button the options "Export to ESRI Shape File" and "Send to Map" are both greyed out. Any suggestions? Charles - how do you output selected data as squares?
David

Yes, you need to include the spatial_ref, spatial_ref_sys, lat and long fields in your report for the report to be usable for any sort of mapping.

Cheers