# [Proj] Lat-Lon values under different ellipsoides

Noel Zinn ndzinn at comcast.net
Fri Feb 6 10:01:41 EST 2009

```Jan,

Not derived from *projected* coordinates (i.e. 3D => 2D) at all.  The
Ordnance Survey have taken you on a tour from one 3D space (lat/lon/height)
to another 3D space (what we're calling geocentric Cartesian coordinates
X/Y/Z, also known as ECEF) and back to the original 3D space
(lat/lon/height, but referenced to a different ellipsoid).  So you've never
left three dimensions even though the Ordnance Survey suggested that you
toss datum B ellipsoid height.

the geocentric Cartesian domain (ECEF is so much easier to write!), that is,
no translations at the geocenter in X, Y or Z and no rotations about any of
these axes and no scale change, then you've *just* switched ellipsoids.
Nevertheless, the resulting change in ellipsoid height is an important clue
that you're not *on* the new ellipsoid.  Once the ellipsoid height is
tossed, the point at that lat/lon on the new ellipsoid with zero height is a
different point than that you started with.

Noel Zinn

_____

From: proj-bounces at lists.maptools.org
[mailto:proj-bounces at lists.maptools.org] On Behalf Of Jan Hartmann
Sent: Friday, February 06, 2009 8:19 AM
To: PROJ.4 and general Projections Discussions
Subject: Re: [Proj] Lat-Lon values under different ellipsoides

As an addition, look how the British Ordnance survey solves the problem of
converting Lat-Lon values from one ellipse to another:

" To summarise: for a simple datum change of latitude and longitude
coordinates from datum A to datum B, first convert to Cartesian coordinates
(formulae in annexe B) taking all ellipsoid heights as zero and using the
ellipsoid parameters of datum A; then apply a Helmert transformation from
datum A to datum B using equation (3); finally convert back to latitude and
longitude using the ellipsoid parameters of datum B (formulae in annexe C),
discarding the datum B ellipsoid height. "

This would mean that different lat-lon values for different ellipsoids are
*derived* from projected coordinates, not the other way round, as I thought.
I still don't get the relationship between those computed lat-lon values and
the astronomical ones though.

Jan

Frank Warmerdam wrote:

Jan Hartmann wrote:

Hi,

This is something I have long been banging my head against. I think it
is a bug, but I am not sure. If I take a lat-lon value, computed on a
particular ellipsoid, and convert it to the lat-lon value on another
ellipsoid, I should get a different value, right? (e.g. cs2cs
+proj=longlat +ellps=bessel +to +proj=longlat +ellps=WGS84). PROJ4
always gives the same value, but I have an extensive list of coordinates
of church towers in the Netherlands with their lat-lon values in 1850,
based an a slightly smaller ellipsoid than we use nowadays, and the
lat-lon of the same towers derived from our modern RD-system, based on
the Bessel-ellipsoid, and without the WGS84 correction. There is a
systematic difference of about 50 meters. If I do the same computation
with the projected coordinates, I get the correct answer. Moreover, in
that case the transformation changes when I change the
ellipse-parameter, something that does not happen with lat-lon coordinates.

So, is this a bug in PROJ? If so, can someone with geodetic experience
here explain to me how people can get different lat-lon values for the
same point, based on astronomical measurements?

Jan,

As of PROJ 4.6.0, the policy is to not attempt any conversion of lat/long
values between coordinate systems where only an ellipsoid is given.  So, to
get a datum shift it is now necessary to provide some sort of datum
shift information for both the source and destination coordinate systems.

This is a deliberate change of policy to avoid lots of other complaints in
the past.

I would suggest using something appropriate like +datum=potsdam for your
Bessel data, and +datum=WGS84 instead of +ellps=WGS84.

Best regards,

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20090206/df316698/attachment.htm
```