Hi Peter, Back in Oct/Now I wrote to Tim Schaub asking about measurements when working with Spherical Mercator and he sent me a few responses that I'm copying below for you.
Regards, Jennifer *First response: *Regarding the measure control, this provides planar instead of geodesic measures (as is true with ArcMap and other GIS software). So, when you measure a length, you are getting the straight-line distance between points on a projected plane instead of the shortest distance between points on a spheroid. Same goes for area - planar area instead of surface area of a spheroid. So, yeah, your spatial reference system is important. And spherical mercator will be worse the farther you are from the equator. So, for a couple points around San Francisco: point 1: -13625500, 4551200 point 2: -13625250, 4551200 planar distance: 250 m geodesic distance: 198 m That is pretty bad. The solution with lines is to use a geodesic calculation (which we provide with OpenLayers.Util.distVincenty). For areas, this is more complicated - as it involves dividing an arbitrary polygon into triangles and running spheroid areas on those (which we don't have a function for in the library). One solution would be to transform the polygon to a more appropriate projection before calculating the area. I can't get in to more detail on this now, but if you haven't found another solution, we can talk more about this. Tim *A few weeks later he sent this:* Hey- In case you don't see it on the OL dev list, I've put up a patch to do geodesic measures with the measure control. This assumes that you have provided the proj4js definitions for your map projection. http://trac.openlayers.org/ticket/1819 Let me know if it works for you. Tim Peter Robins wrote: > I have a program that displays kml linestrings on either topo maps or google. > I'm using getLength() to display the length of the segments, and noticed > significant errors on the google display, in some cases 60% or more. I'm > also using the scaleline, which is also wrong on Google. > > Thinking this was probably some error in my logic, I tried some simple tests. > The topo maps conveniently include a 1km grid, so I drew some 1km lines on > the grid (as close as I could make it) and saved them to kml. This gave me > coordinates that I knew were 1km apart (on the topomap projection). I then > used the Google api: > > var p1 = new GLatLng(42.87420777239693,-8.547039046722437); > var p2 = new GLatLng(42.87483907990915,-8.534868375601192); > alert(p1.distanceFrom(p2)); > > This gave me 0.995km, so Google agrees that these 2 points are 1km apart. > (Google's docs say their calculations may be up to 0.3% out because of the > spherical assumption they use; this is no problem at the scales I'm using.) > > I then took OL's spherical mercator example page, and added my kml file. The > scale line incorrectly showed the 1km line as well over 1km long. I then did: > > var p1 = new OpenLayers.Geometry.Point(-8.534868375601192,42.87483907990915); > p1.transform(map.displayProjection, map.projection); > var p2 = new OpenLayers.Geometry.Point(-8.547039046722437,42.87420777239693); > p2.transform(map.displayProjection, map.projection); > alert(p1.distanceTo(p2)); > > This gave me 1.358km. > Thinking there might be some problem with the spherical mercator > calculations, > I tried removing 'sphericalMercator: true' and using proj with different > projection objects. I found several defs on spatialreference.org, > and used SR-ORG:6 and SR-ORG:6627; I also used the new EPSG:3785. These defs > are all very similar, so I was not surprised to get the same error: 1358m. > > Those 2 points are in Spain, EPSG:23030, but I also tried other places. One > 5.2km line in GB, as measured on OS maps, EPSG:27700, was 8.4km according to > OL Google getLength(). > > I would expect discrepancies when dealing with different projections. I would > expect rounding errors when transforming lots of points on a linestring. But > these errors are so large the figures are effectively useless. > > Am I doing something wrong, or missing some vital step somewhere? Is it an > error in OL's calculations? Or is it one of those complicated projection > issues, where it would be simpler to use Google's api not OL if I want > linestring lengths? > _______________________________________________ > Users mailing list > [email protected] > http://openlayers.org/mailman/listinfo/users > -- Jennifer Strahan, GIS Specialist GreenInfo Network - www.greeninfo.org - Information and Mapping in the Public Interest **As of Oct. 13, 2008 we have a new address** 564 Market Street, Suite 510 San Francisco CA 94104 Phone: 651-917-0191 Fax: 415-979-0371 Email: [email protected] _______________________________________________ Users mailing list [email protected] http://openlayers.org/mailman/listinfo/users
