On Mon, Jun 28, 2004 at 08:20:20AM -0700, Jo Walsh wrote:

On Mon, Jun 28, 2004 at 06:48:23AM -0400, IvorW wrote:

...

I thought that you needed different ellipsoids for different parts of the globe. wgs84 or nad83 may work well for California, but I doubt if they would for Europe.

no, wgs84 is a global model. streetmap.co.uk gives you lat and long back in wgs84. you need to worry about the different archaic

reference datums used in different countries grid projections only when projecting geodata onto flat maps that are already georeferenced according to the other projection.

UTM is where this makes a difference for different countries grid systems - i wouldn't know my own local mapping agency

projection, though...

i would send a link with better metainfo but have to run...

There is another, equally valid consideration relating to ellipsoids, which is this:

The distances under a different ellipsoid will not match the distances on the globe. I stand to be corrected if I am wrong - but the Earth is the shape of a squashed tomato or an apple at best. If you are outside the region the projection is targetted at, you will find that the distances are considerably stretched or shrunk along one or other of the axes, making them useless for actual distance measurement.

An ellipsoidal projection about one great circle will only provide an accurate projection regarding distances, for a very small percentage of locations on Earth.

This is a classic case of YMMV (in this case YMCWV :).

Part of the use of the geographical data and locator plugins is to provide distance measures that are usable and useful.

However, I am willing to entertain using wgs84 as the default ellipsoid if there are no objections. But I feel that most of us will want to specify our favourite ellipsoid, just so as to get distances that are workable, regardless of whether the mapping fits any national standard in the country in question.

Ivor.

IvorW wrote:

An ellipsoidal projection about one great circle will only provide an accurate projection regarding distances, for a very small percentage of locations on Earth.

I know we've talked about simply calculating distances from point A to point B on the surface of a sphere in the past, and rejected it because you lose accuracy over small distances, due to rounding errors in cos() and sin().

I wonder, if we used an arbitrary precision FP library like Math::BigFloat does this problem go away? It doesn't provide trig functions, but they can be derived thus:

cos(x) = 1 - x^2/2! + x^4/4! - x^6/6! + ... (x in radians)

and

sin(x) = x - x^3/3! + x^5/5! - x^7/7! + ...

This is guaranteed to give us accurate results provided we use sufficiently accurate values for sin(x) and cos(x), I wonder what the performance hit would be.