[Proj] Lat-Lon values under different ellipsoides

[Noel Zinn]

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.

 

You've previously asked about an ellipsoid switch.  If nothing happens in
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.osgeo.org/pipermail/proj/attachments/20090206/df316698/attachment.html>