This project has moved and is read-only. For the latest updates, please go here.

Bug when tryin' to convert Proj2Geog and Geog2Proj

Mar 10, 2007 at 11:25 PM
Edited Mar 10, 2007 at 11:29 PM
There's no check whether datum transformation is necessary or not. Imagine you want to convert from UTM (based on WGS84 ellipsoid) to Bessel 1841 geographic coordinates... I've fixed the bug and have sent the files via mail. Hope you received it...
Mar 11, 2007 at 11:52 AM
If you specify the TOWGS84 parameter on the datum, SharpMap will automatically perform the datum transform. If not, it has no way of knowing tha datum shifts it needs to apply, and just ignores the datum transform step.
Mar 11, 2007 at 7:57 PM
Edited Mar 12, 2007 at 8:39 AM
Methods Geog2Proj and Proj2Geog do not check TOWGS84 parameter at all.
Mar 11, 2007 at 8:16 PM
Yes, you can define a projected coordinate system with underlying geographic coordinate system and datum(e.g. UTM on WGS84). But when you convert this Proj2Geog - let's say to Bessel 1841 geographic coordinates - there's just the inverse Transverse Mercator Transformation without considering that there's a datum shift obligatory. The same problem occurs when converting Geog2Proj.
Mar 11, 2007 at 9:45 PM
Where can I find Geog2Proj and Proj2Geog?
Mar 11, 2007 at 10:06 PM
Just ignore my question. Cheers.
Mar 11, 2007 at 10:33 PM
Axyonych: Yes it does - but you are looking in the wrong place.
The datum transformation is done in Geoc2Geoc. Datum transformations has to be done in a geocentric coordinate system. When you specify two projections as input, each with their own datum, the transformation factory will create a list of transformations that it will use:
1. Proj2Geo (datum1)
2. Geo2Geoc (datum1)
3. Geoc2Geoc (datum1->datum2)
4. Geoc2Geo (datum2)
5. Geo2Proj (datum2)

If the datums are the same (or no TOWGS84 datum transform is specified) 2-4 will be skipped. If the from coordinate system is geographic, step 1 will be skipped and vice versa on step 5.

To clarify: The geocentric coordinate system is a "normal" XYZ coordinate system with the origo (0,0,0) at the center of the earth. Unfortunately we don't know the correct center of the earth. Instead we define an approximate form of the earth (the ellipsoid), a center and an orientation of it. These parameters make up the datum.
Some datums are more accurate on certain places on the Earth than others (ie. NAD87 is meant to be used in North America and ED50 in Europe). The datum transform basically offsets, rotates and scales the XYZ coordinate system so it fits with another definition. Unfortunately the parameters to do this are not constant, and is dependent on where you are located on the earth. Therefore a specific set of TOWGS84 may be good in one area, but bad in another. Usually the national cadastre, geological survey or who ever takes care of that in your country knows these parameters.
Mar 11, 2007 at 11:11 PM
@Odegaard: Your are right with what you say. The ConcatenatedTransform you speak about happens in the CreateGeog2Geog method. A datum shift is done correctly by the steps you mentioned. But believe me: in Proj2Geog and Geog2Proj it is not, since a geocentric transformation as required is never impelled there.And this is exactly the mistake.
Mar 12, 2007 at 2:18 AM
Hmm I see your point. It is obviously missing in CoordinateTransformationFactory.cs. It's only implemented in Geog2Geog and Proj2Proj.
Basically it should use the code from CreateProj2Proj to accomplish this, but remove either the first or the last transform depending on whether it is to or from a projection. A small optimization could be made by only using the concatenated transform if a datum shift or prime meridian change is required - if not the current code is sufficient.

Can someone copy this to the issue list, and add it in the unit tests? This should also be copied to NetTopologySuite and MsSqlSpatial which uses this code.
Mar 14, 2007 at 12:37 AM
This discussion has been copied to Work Item 8893. You may wish to continue further discussion there.