Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

I have a mapping website used to capture polygons using OpenLayers in Google projection (900913) and storing them in sql server 2008 as geometry. The SRID on the sql geometry column is set to 900913. I don't reproject from the captured data, it's just sent to the server as WKT format from the features in OpenLayers and inserted into a geometry column using geometry::STGeomFromText().

When I call STArea() on the geometry I get hugely inaccurate results. For example, we have a gridded ordnance survey tile service that projects to 900913. If I trace a polygon as a 1km grid square from this background image and save it, the coordinates of the square in 900913 come out as around 1660m apart instead of 1000m and the total area is 2.7km2 instead of 1km2. This is baffling. The units of the Google projection are supposed to be in metres but metres of what?

If I import the geometry into Quantum GIS, I can calculate the area using the measure area tool. If I have the 'Ellipsoidal' checkbox on, I get the right calculation (1km2 in example above) and with ellipsoidal off, I get the inaccurate result (2.7km2).

There's a big gap in my knowledge here, but it looks like, despite the fact Google is a projected coordinate system, you can't use geometry methods for distance and area. You have to take into account the ellipsoid/sphere to get anything accurate. Is this true? Are there any good resources to find out more about this (I've seen the discussion on Alistair Aitchison's blog but there's quite a bit of assumed knowledge that I don't have towards the end)

The polygon capture on the OpenLayers map needs to be in 900913 so I can use Bing background mapping etc. So should I re-project before saving to sql server? If so, what would be appropriate (the extent of the mapping is UK which is both OSGB and OSI grids)?

In short, how should polygons captured in Google projection be stored if you want accurate area and distance calculations?

Thanks in advance for any pointers that might shed light on this.

share|improve this question
add comment

2 Answers 2

up vote 1 down vote accepted

You have to enable the geodesic option on the OpenLayers measure control to get correct measurements.

This discussion here should help you understand what is going on (tip: the Earth is not flat as Google/Bing Maps shows it ;-) ):

Using Geodesic Measurements for Circle Radii?

Make sure you read the comments, in particular this one.

share|improve this answer
    
Thank you. This is the kind of pointer I was looking for. I suspect I've just forgotten to consider the limitations of different projection systems. but the error of 660m over 1000m completely surprised me. This question link –  andyb Aug 18 '12 at 20:47
    
Ah took to long to edit my comment! –  andyb Aug 18 '12 at 20:54
add comment

I don't know much about what you are doing, but I too have been having problems similar to yours when overlaying vectors on OpenLayers (in my case, using QGIS and the OpenLayers plug-in).

It seemed like a bright idea to make a vector grid for my area of interest with lines at horizontal and vertical intervals 1000 metres. I saved the grid in my usual CRS, EPSG:27700, and then tried overlaying it on OpenStreetMap, using QGIS and the OpenLayers plug-in. QGIS tranformed the grid on-the-fly and plotted it, but with large positional errors and also with the sort of problems you found when measuring distances and areas.

Now, here's the strange thing. I thought I'd try reprojecting my grid shapefile from EPSG:27700 to EPSG:3857 and trying this in OpenLayers. To my surprise it not only plotted perfectly, but is was also possible to measure distances properly (for example, the four sides of one of my 1000 metre grid squares totalled 4000 metres).

It seems possible that the problems arise when any layer in the mix is being reprojected on-the-fly, which is what I understand is happening to your Ordnance Survey data. As a test, perhaps it might be worth warping a piece of OS raster mapping to EPSG:3857 and then overlaying it on OpenLayers to see if the problem goes away (I haven't tried this).

Like you, I'm stuck for an explanation of what is happening.

Nick.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.