[OSRS-PROJ] datum shift Gauss Krueger
Clifford J Mugnier
cjmce at lsu.edu
Thu Jun 13 09:22:49 EDT 2002
Gentlemen:
The parameters found in Dr. Dana's Colorado web site were last updated in
1997. For the latest listing of what's available (from the original
source), see the www.NIMA.mil web site that will have links to the gandg
(Geodesy and Geophysics) web site for "TR8350.2" which is the defining
document for WGS84. Addtional shift parameters may be garnered from the
EPSG web site somewhere in Switzerland and also from my monthly columns in
"Photogrammetric Engineering and Remote Sensing." (Listed below my
signature block).
Gauss-Krueger has nothing to do with a datum shift. It is the basic
projection behind the DHG Grid. (Deutches Herres Gitter). The Russia Belts
are the same sort of system on a different Datum and ellipsoid. There are
literally thousands of possible Datum shift parameters that have never been
published. Each and every one has to be individually solved for, and the
solutions can have a variety of parameters depending on the intended usage.
The most common is the 3-parameter which only involves translations plus
the difference between the ellipsoid dimensions and shapes.
Each solution needs a number of points in which the coordinates are known
on both Datums. The solution for the systematic error between the two
Datums then yields the parameters for the shift model used. For military
purposes the accuracy is not that stringent because of the blast radius of
artillery shells. (Not kidding!) Some countries have allowed the U.S.
military to use more points in the published (public) solution as a service
to civilian users. If the published values are not available for the
region of the world that is of interest to you, it is because of one of two
reasons: that country does NOT want the parameters publicly known, or no
one has ever bothered to solve for the parameters because there's little
economic incentive for GIS & mapping in the area.
If you have access to a number of points with coordinates in two Datums,
send the data to me and I'll be happy to solve the parameters for you. The
more points the better, as long as it is actual survey points on the
ground. Digitized paper map data is not suitable for such an approach.
Regards,
Prof. Clifford J. Mugnier (cjmce at LSU.edu)
Chief of Geodesy
CENTER FOR GEOINFORMATICS
Department of Civil Engineering
LOUISIANA STATE UNIVERSITY
Baton Rouge, LA 70803
Voice and Facsimile: (225) 578-8536
Pager: 1-(888) 365-5180
================================
http://www.ASPRS.org/resources.html
http://www.ce.LSU.edu/~mugnier/
================================
Hi,
while not being very familiar with datum transformations, a suggestion
to below problem. The Peter Dana's web site shows a different
Potsdam_Rauenberg_DHDN datum:
http://www.colorado.Edu/geography/gcraft/notes/datum/dlist.html
A quick try:
cs2cs +proj=latlong +datum=WGS84 +to +init=epsg:31494 +towgs84=606,23,413
Some results with above datum:
Frans de Roos tried:
lat/long 11.60608768 48.25167084
new cs2cs: 4470850.92 5346045.81
expected: 4470860.075 5346044.934 (less error than he got, see below)
Harald Wehr tried:
lat/long 10.69079E 51.86134N
new cs2cs: 4409913.94 5748285.09
expected: 4409920 5748280 (less error than he got, see below)
Regards
Markus Neteler
On Thu, Jun 13, 2002 at 07:24:30AM +0200, Frans de Roos (EPL) wrote:
> Hello All
>
> I got the same problem as Harald Wehr when tranforming from wgs84 to
> Gauss-Krueger (zone 4) . My transformation will also be about 55 meters
> wrong.
>
> I use cs2cs as follow
> cs2cs +proj=latlong +datum=WGS84 +to +proj=tmerc +ellps=bessel
> +lat_0=0 +lon_0=12 +x_0=4500000 +towgs84=583,68,399
>
> What I know from some other program I should use
>
> Gauss Krueger 4, Bessel, Potsdam_IST_V2_0
> 583.00 - Translation dx in meter to WGS84
> 68.0 - Translation dy in meter to WGS84
> 399.50 - Translation dz in meter to WGS84
> 0 - Rotation ro (omega) in Radiant to WGS84
> 0 - Rotation rf (phi) in radiant to WGS84
> 13.6e-06 - Rotation rk (Kappa) in Radiant to WGS84
> 11.3e-06 - Mapscale factor in ppm (parts per million) to WGS84
>
> And tranformation should calculate
>
> ID lon (WGS84) lat (WGS84) X (GK4) Y (GK4)
> 1 11.60608768 48.25167084 4470860.075 5346044.934
> 2 10.96510029 50.25949478 4426313.445 5569780.810
> 3 7.46 51.57 4185407.951 5724830.919
>
> When I use cs2cs I get the X-value to be about 55 meters wrong! The
Y-value will just differ 0 - 3 meter.
> I think that I should in some way add the rotation kappa in the
calculation! Does anyone know how how I should do this?
>
> If I change the dy value from 68 to 18 I got some better values. Now the
X and Y values will differ about 8 meters but I don't think I should do
this.
>
> Frans
>
>
>
>
>
>
> Dear Frank,
>
> The Europeans like to do their rotations in an opposite direction
from the
> rest of the world when doing 7-parameter Datum Shifts.
Translation and
> Scale Factors remain the same. e.g., you will get weird and
unexplainable
> results if you rotate in the wrong direction.
>
> A Helmert transform done with geocentric coordinates in three
dimensions is
> called a Helmert Direct from Geodetic to Geocentric, and is
called a
> Helmert Inverse from Geocentric to Geodetic.
>
> Molodensky-Badekas does a 3-d Helmert direct to geocentric
coordinates,
> subtracts the geocentric coordinates of the classical Datum
origin, then
> does the 7-parameter, then finally does the Helmert inverse back
to the new
> Datum's geodetic coordinates.
>
> Bursa-Wolf does a 3-d Helmert direct to geocentric coordinates,
does NOT
> subtract the geocentric coordinates of the classical Datum
origin, then
> does the 3-parameter, or 4-parameter, or 7-parameter, then
finally does the
> Helmert inverse back to the new Datum's geodetic coordinates.
>
> How do you tell which direction to rotate? It is impossible
unless you
> have a test point. Since Harald does have a test point ...
>
> So now you know.
>
> Cliff
>
> Prof. Clifford J. Mugnier (cjmce at LSU.edu)
> Chief of Geodesy
> CENTER FOR GEOINFORMATICS
> Department of Civil Engineering
> LOUISIANA STATE UNIVERSITY
> Baton Rouge, LA 70803
> Voice and Facsimile: (225) 578-8536
> Pager: 1-(888) 365-5180
> ================================
> http://www.ASPRS.org/resources.html
> http://www.ce.LSU.edu/~mugnier/
> ================================
>
>
> Harald Wehr wrote:
> > Hi Frank,
> >
> > first i apologize, that i contact you directly.
> >
> > In the PROJ.4-mailing-list no one answered to my problem.
Attached you
> > find my mail from february 26th that I send to the list.
> ...
>
> > I want to convert some data from latlong/wgs84 to tmerc/bessel
with
> > datum shift from wgs84 to potsdam-datum here in germany. How
do i have
> > to use the function? Are helmert-7-parameter as well as
> > molodenski-3-parameter implemented? I tried the following:
>
> Harald,
>
> I didn't answer because I am always getting confused about the
terminology
> for some of the different transforms. There is a three and seven
> parameter transform implemented; however, I am not certain that
the
> interpretation of the parameters (sign, handedness, etc) is
exactly what
> is defined for helmert and molodenski. I think it is though.
>
> >
> > --------
> > cs2cs -v +proj=latlong +to +proj=tmerc +ellps=bessel +lat_0=0
+lon_0=12
> > +x_0=4500000 +towgs84=-586,-87,-409 <<EOF
> > 10.69079E 51.86134N
> > EOF
> > --------
> >
> > As result i get the following:
> >
> > ---------
> > # ---- From Coordinate System ----
> > #Lat/long (Geodetic)
> > #
> > # +proj=latlong +ellps=WGS84
> > # ---- To Coordinate System ----
> > #Transverse Mercator
> > # Cyl, Sph&Ell
> > # +proj=tmerc +ellps=bessel +lat_0=0 +lon_0=12 +x_0=4500000
> > # +towgs84=-586,-87,-409
> > #--- following specified but NOT used
> > # +ellps=WGS84
> > 4409820.23 5748070.07 698.769
> >
> > ---------
> >
> > The result is not good enough. I expect something like that:
> > 4409920 5748280.
> >
> > Whats wrong here? I got the "towgs"-parameters from a another
> > helmert-calculation i found in the internet which work in
another
> > program i have here and show the results i expected.
>
> First, no actual datum shift is being applied in this case
because PROJ
> doesn't equate +ellps=WGS84 with the WGS84 datum automatically.
I realized
> this when I did the conversion without the +towgs84 parameter and
got the
> same results. Please use +datum=WGS84 to force treatment of the
lat/long
> coordinates as being the WGS84 datum.
>
> Howwever, this doesn't seem to get us any closer to your expected
values.
>
> warmerda at gdal[355]% cs2cs +proj=latlong +datum=WGS84 +to
+proj=tmerc
> +ellps=bessel
> +lat_0=0 +lon_0=12 +x_0=4500000 +towgs84=-586,-87,-409 < test.dat
> 4409793.19 5747857.54 1386.040
>
> I tried reversing the sign of the offset, as this is a frequent
> incompatibility,
> and get:
>
> warmerda at gdal[356]% cs2cs +proj=latlong +datum=WGS84 +to
+proj=tmerc
> +ellps=bessel
> +lat_0=0 +lon_0=12 +x_0=4500000 +towgs84=586,87,409 < test.dat
> 4409847.28 5748282.64 11.504
>
> This is close to what you expect in the northing (2m), but no so
close in
> the
> easting - still off by 70m or so. I am no sure what else to say.
>
> Best regards,
>
>
>
>
>
>
> ----------------------------------------
> PROJ.4 Discussion List
> See http://www.remotesensing.org/proj for subscription, unsubscription
> and other information.
----------------------------------------
PROJ.4 Discussion List
See http://www.remotesensing.org/proj for subscription, unsubscription
and other information.
----------------------------------------
PROJ.4 Discussion List
See http://www.remotesensing.org/proj for subscription, unsubscription
and other information.
More information about the Proj
mailing list