DHDN / Gauss Krueger to WGS84

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

DHDN / Gauss Krueger to WGS84

Oliver Eichler-2
Hi,

looks like this question has been posted in the past, but blimey, I
could not extract a simple answer that I do understand. Thus  I would
like to rephrase the question in the hope to get an easy to use answer
for someone not deep in geo math at all :)

I do have a coordinate in easting/northing [m] from a raster map  using
Gauss Krüger projection and Potsdam datum. Now I would like to get the
lon/lat coordinate on a WGS84 ellipsoid. And vice versa. I would like to
use the proj4 C API not the command line.

Can any kind soul take me by the hand and point me to some tutorial or
give me a quick guided tour?

Thanks,

Oliver

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: DHDN / Gauss Krueger to WGS84

Oliver Eichler-2

> I do have a coordinate in easting/northing [m] from a raster map  using
> Gauss Krüger projection and Potsdam datum. Now I would like to get the
> lon/lat coordinate on a WGS84 ellipsoid. And vice versa. I would like to
> use the proj4 C API not the command line.
>
>  

Ok, further investigations condensed into something like:

pjgaukru = pj_init_plus("+init=epsg:31467");
pjwgs84 = pj_init_plus("+init=epsg:4326");

// easting / northing to lon / lat
pt = pj_inv(pt,pjgaukru)

//???
double z = 0;

pj_datum_transform(pjgaukru, pjwgs84, 1, 0, &pt.u, &pt.v, &z);

However the result is still several minutes away from the expected
coordinate. What do I miss?

Oliver


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: DHDN / Gauss Krueger to WGS84

Frank Warmerdam
Oliver Eichler wrote:

>> I do have a coordinate in easting/northing [m] from a raster map  using
>> Gauss Krüger projection and Potsdam datum. Now I would like to get the
>> lon/lat coordinate on a WGS84 ellipsoid. And vice versa. I would like to
>> use the proj4 C API not the command line.
>>
>>  
>
> Ok, further investigations condensed into something like:
>
> pjgaukru = pj_init_plus("+init=epsg:31467");
> pjwgs84 = pj_init_plus("+init=epsg:4326");
>
> // easting / northing to lon / lat
> pt = pj_inv(pt,pjgaukru)
>
> //???
> double z = 0;
>
> pj_datum_transform(pjgaukru, pjwgs84, 1, 0, &pt.u, &pt.v, &z);
>
> However the result is still several minutes away from the expected
> coordinate. What do I miss?

Oliver,

How about:

pjgaukru = pj_init_plus("+init=epsg:31467");
pjwgs84 = pj_init_plus("+init=epsg:4326");

//???
double z = 0;

pj_datum_transform(pjgaukru, pjwgs84, 1, 0, &pt.u, &pt.v, &z);

Don't forget that the output is pt.u with the longitude in
radians, and pt.v with the latitude in radians.  The call
you make to pj_inv() is duplicating work that is done by
pj_transform() (corrupting really).

I would add that epsg:31467 expands as:

+proj=tmerc +lat_0=0 +lon_0=9 +k=1.000000 +x_0=3500000 +y_0=0 +ellps=bessel
+datum=potsdam +units=m +no_defs

Note that this definition is using +datum=potsdam which expands to:

   +ellps=bessel +towgs84=606.0,23.0,413.0

This may or may not be the best datum shift parameters for your area of
work.  You may need to research a better local shift.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: DHDN / Gauss Krueger to WGS84

Oliver Eichler-2
Hi Frank
> pjgaukru = pj_init_plus("+init=epsg:31467");
> pjwgs84 = pj_init_plus("+init=epsg:4326");
>
> //???
> double z = 0;
>
What is the z parameter for? Height?

>
> I would add that epsg:31467 expands as:
>
> +proj=tmerc +lat_0=0 +lon_0=9 +k=1.000000 +x_0=3500000 +y_0=0
> +ellps=bessel +datum=potsdam +units=m +no_defs
>
> Note that this definition is using +datum=potsdam which expands to:
>
>   +ellps=bessel +towgs84=606.0,23.0,413.0
>
That should be ok. These are maps from "Bayerisches
Landesvermessungsamt". Hope they know what they are doing.
> This may or may not be the best datum shift parameters for your area of
> work.  You may need to research a better local shift.
>
Does that mean that the shift parameters depend on the location within
the map? Or that the whole map might have some kind of bad offset
produced by a bad projection?

And how would I get better shift parameters? Is there a tutorial somewhere?

Thanks,

Oliver


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: DHDN / Gauss Krueger to WGS84

Frank Warmerdam
Oliver Eichler wrote:
>> This may or may not be the best datum shift parameters for your area of
>> work.  You may need to research a better local shift.
>>
> Does that mean that the shift parameters depend on the location within
> the map? Or that the whole map might have some kind of bad offset
> produced by a bad projection?
>
> And how would I get better shift parameters? Is there a tutorial somewhere?

Oliver,

The 3/7 parameter +towgs84 parameters are just used for an approximate
transformation between datums. Sometimes, especially for old datums, the
differences are quite irregular over the area of the datum and are not well
represented by a simple transformation.

So, you will often see datums having various towgs84 parameters, some which
might be a decent general transformation over a large area and others which
might be a more accurate transformation in a fairly local area of the
datum.

Ugly, isn't it?

No, there is no obvious way to get better parameters other than researching
various source (ie. national mapping agencies, other publications, ask other
users in your region).

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: DHDN / Gauss Krueger to WGS84

Oliver Eichler-2

>
> Ugly, isn't it?
>
> No, there is no obvious way to get better parameters other than
> researching
> various source (ie. national mapping agencies, other publications, ask
> other
> users in your region).
>
Hi Frank,

I feared you will say that. Well as the original data and software is
able to geo-reference the map correctly I guess I have to look for the 3
or 7 values in the original data. At least I know now what to look for :)

On last question: the z parameter for pj_transform() is the height isn't
it?

Oliver
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

AW: DHDN / Gauss Krueger to WGS84

Uwe Schmitz-2
In reply to this post by Oliver Eichler-2
Oliver,

>
> Oliver Eichler wrote:
> >> This may or may not be the best datum shift parameters for
> your area of
> >> work.  You may need to research a better local shift.
> >>
> > Does that mean that the shift parameters depend on the
> location within
> > the map? Or that the whole map might have some kind of bad offset
> > produced by a bad projection?
> >
> > And how would I get better shift parameters? Is there a
> tutorial somewhere?
>
> Oliver,
>
> The 3/7 parameter +towgs84 parameters are just used for an approximate
> transformation between datums. Sometimes, especially for old
> datums, the
> differences are quite irregular over the area of the datum
> and are not well
> represented by a simple transformation.
>
> So, you will often see datums having various towgs84
> parameters, some which
> might be a decent general transformation over a large area
> and others which
> might be a more accurate transformation in a fairly local area of the
> datum.
>
> Ugly, isn't it?
>
> No, there is no obvious way to get better parameters other
> than researching
> various source (ie. national mapping agencies, other
> publications, ask other
> users in your region).

please take a look at
http://crs.bkg.bund.de/crseu/crs/descrtrans/BeTA/de_dhdn2etrs_beta.php

There you will find information about a "standard" solution
for your problem. The documentation gives a brief example
for using PROJ.4. (I think, the german language isn't a problem
for you :-)).

If you have any problems, please let me know.

Best wishes
Uwe
---------------------------------------------------------
... Uwe Schmitz  Landesvermessungsamt Nordrhein-Westfalen
... Muffendorfer Str. 19 - 21              D - 53177 Bonn
... E-mail:       [hidden email]
... Internet:     http://www.lverma.nrw.de


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: DHDN / Gauss Krueger to WGS84

Frank Warmerdam
In reply to this post by Oliver Eichler-2
Oliver Eichler wrote:
> On last question: the z parameter for pj_transform() is the height isn't
> it?

Oliver,

Yes, sorry for not answering that aspect the first time around.

Some transformation (such as datum shifts and changes of ellipsoid) can
also alter the elevation about the ellipsoid so we provide a z to transform
even if we ignore the results.

Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, [hidden email]
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush    | President OSGeo, http://osgeo.org

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: AW: DHDN / Gauss Krueger to WGS84

Oliver Eichler-2
In reply to this post by Uwe Schmitz-2
[hidden email] wrote:

> please take a look at
> http://crs.bkg.bund.de/crseu/crs/descrtrans/BeTA/de_dhdn2etrs_beta.php
>
> There you will find information about a "standard" solution
> for your problem. The documentation gives a brief example
> for using PROJ.4. (I think, the german language isn't a problem
> for you :-)).
>
> If you have any problems, please let me know.
>
>  
Hi Uwe

Ok, had a look at it. Maybe it's a dump question (I am really not
professional in this area) but as my target datum is WGS84 shouldn't I
use different shift factors than for ETRS89?

Or is the shift from ETRS89 to WGS84 independent from the actual
location? Google gives me the impression that it is.

Oliver
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: AW: DHDN / Gauss Krueger to WGS84

Dean Mikkelsen
Hi Oliver,
 
No question is ever dumb. If no one ever asks, no one can ever learn.
 
A technical definition from Wikipedia states:
 
"The European Terrestrial Reference System 1989, usually referred to as ETRS89, is a three-dimensional geodetic frame of reference - a mapping coordinate system used as the standard high accuracy system for GPS in Europe.
 
It coincided with the World Geodetic System 1984 in 1989, hence the name, and is based on the same GRS80 ellipsoid. Unlike WGS84 or ITRS it is centred on Europe and diverges from them with the movements of the tectonic plates associated with this landmass."
 
Please see: http://en.wikipedia.org/wiki/ETRS89 for ETRS89
                 and  http://en.wikipedia.org/wiki/World_Geodetic_System_1984 for WGS84
 
These are some pretty good description of some systems used in Geodesy.
 
Cheers,
Dean
 
 

----- Original Message -----
From: Oliver Eichler <[hidden email]>
Date: Friday, September 21, 2007 8:59 am
Subject: Re: AW: [Proj] DHDN / Gauss Krueger to WGS84
To: "PROJ.4 and general Projections Discussions" <[hidden email]>

> [hidden email] wrote:
> > please take a look at
> >
> http://crs.bkg.bund.de/crseu/crs/descrtrans/BeTA/de_dhdn2etrs_beta.php>
> > There you will find information about a "standard" solution
> > for your problem. The documentation gives a brief example
> > for using PROJ.4. (I think, the german language isn't a problem
> > for you :-)).
> >
> > If you have any problems, please let me know.
> >
> >  
> Hi Uwe
>
> Ok, had a look at it. Maybe it's a dump question (I am really not
> professional in this area) but as my target datum is WGS84
> shouldn't I
> use different shift factors than for ETRS89?
>
> Or is the shift from ETRS89 to WGS84 independent from the actual
> location? Google gives me the impression that it is.
>
> Oliver
> _______________________________________________
> Proj mailing list
> [hidden email]
> http://lists.maptools.org/mailman/listinfo/proj
>

Dean C. Mikkelsen, B.Sc., P.Eng.
Terra ETL Ltd.
Mobile/Cellphone: +1 250 361 6672
E-mail: [hidden email]



_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: AW: DHDN / Gauss Krueger to WGS84

Dean Mikkelsen
Hi Oliver,
 
I forgot to add the following:
 
The parameters for a datum shift (dx, dy, dz, rx, ry, rz, etc.) between ETRS89 and WGS84 are not constant, due to the movement of the Eurasian geophysical plate with respect to WGS84. The differences between both datums can grow by several centimetres a year. Currently they are a couple of decimetres in difference. For many applications, these differences are not relevant. Coordinates or positions in WGS84 have usually been obtained by GPS and this results in an accuracy at the level of several metres. However, satellite positioning techniques continuously improve in accuracy, also without using differential stations. So the differences between the datum's will grow. Note that many nations are using WGS84 to define boundaries nowadays - so WGS84 is relevant.
 
In your case and for your application, I do believe you will be fine using ETRS89.
 
Cheers,
Dean
 


----- Original Message -----
From: Dean Mikkelsen <[hidden email]>
Date: Friday, September 21, 2007 10:26 am
Subject: Re: AW: [Proj] DHDN / Gauss Krueger to WGS84
To: [hidden email], "PROJ.4 and general Projections Discussions" <[hidden email]>
Cc: "PROJ.4 and general Projections Discussions" <[hidden email]>, [hidden email]

> Hi Oliver,
>  
> No question is ever dumb. If no one ever asks, no one can ever learn.
>  
> A technical definition from Wikipedia states:
>  
> "The European Terrestrial Reference System 1989, usually
> referred to as ETRS89, is a three-dimensional geodetic frame of
> reference - a mapping coordinate system used as the standard
> high accuracy system for GPS in Europe.
>  
> It coincided with the World Geodetic System 1984 in 1989, hence
> the name, and is based on the same GRS80 ellipsoid. Unlike WGS84
> or ITRS it is centred on Europe and diverges from them with the
> movements of the tectonic plates associated with this landmass."
>  
> Please see: http://en.wikipedia.org/wiki/ETRS89 for ETRS89
>                  and  http://en.wikipedia.org/wiki/World_Geodetic_System_1984 for WGS84
>  
> These are some pretty good description of some systems used in
> Geodesy. 
> Cheers,
> Dean
>  
>  
>
> ----- Original Message -----
> From: Oliver Eichler <[hidden email]>
> Date: Friday, September 21, 2007 8:59 am
> Subject: Re: AW: [Proj] DHDN / Gauss Krueger to WGS84
> To: "PROJ.4 and general Projections Discussions"
> <[hidden email]>
> > [hidden email] wrote:
> > > please take a look at
> > >
> >
> http://crs.bkg.bund.de/crseu/crs/descrtrans/BeTA/de_dhdn2etrs_beta.php>> > There you will find information about a "standard" solution
> > > for your problem. The documentation gives a brief example
> > > for using PROJ.4. (I think, the german language isn't a problem
> > > for you :-)).
> > >
> > > If you have any problems, please let me know.
> > >
> > >  
> > Hi Uwe
> >
> > Ok, had a look at it. Maybe it's a dump question (I am really not
> > professional in this area) but as my target datum is WGS84
> > shouldn't I
> > use different shift factors than for ETRS89?
> >
> > Or is the shift from ETRS89 to WGS84 independent from the actual
> > location? Google gives me the impression that it is.
> >
> > Oliver
> > _______________________________________________
> > Proj mailing list
> > [hidden email]
> > http://lists.maptools.org/mailman/listinfo/proj
> >
>
> Dean C. Mikkelsen, B.Sc., P.Eng.
> Terra ETL Ltd.
> Mobile/Cellphone: +1 250 361 6672
> E-mail: [hidden email]
>
>

Dean C. Mikkelsen, B.Sc., P.Eng.
Terra ETL Ltd.
Victoria, B.C., Canada
Phone: +1 (250) 361-6672
http://www.terraetl.com

Consulting in Geodesy & GIS  for the Natural Resources


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

DHDN / Gauss Krueger to WGS84

Uwe Schmitz-2
In reply to this post by Oliver Eichler-2
Dean,

very good explanation, thank you!

Regards,
Uwe

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: DHDN / Gauss Krueger to WGS84

Oliver Eichler-2
Hi Uwe and Dean,

it seems to work. A reference point of:

x = 4459750 m  y = 5448182 m

is converted to

E11.446588 N49.169494

The GeoGrid Viewer (Uwe should know) tells me:

E11.44662  N49.16951

That is approx. 1 or 2 meters apart. I can't tell if that is a normal
error because of the different calculation code. But I guess I have to
be happy with it :) .

BTW can anyone tell me why on earth the Europeans define a datum that is
identical to WGS84 in 1989 but will have an increasing error over the
years? Is that politics or just to keep things, located in Europe, from
'moving' (in respect to WGS84)?

Thank you all for your answers.

Oliver
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: AW: DHDN / Gauss Krueger to WGS84

support.mn
In reply to this post by Oliver Eichler-2
Hello all!

We have solved this problem with moving plates by adding a simple date with the coordinates of WGS84. That way you can always go back to the original position of that particular date in WGS84 (or any). The WGS84 datum (with date)  will stay accurate for ever, since it is always possible to trace back where the plates were at that specific date.

latitude,
longitude,
(WGS84),
date

That's it. At the moment we don't need this feature, but it is there to be sure that the positions recorded will always stay accurate.

Regards Janne.

---------------------------------

> I forgot to add the following:
>  
> The parameters for a datum shift (dx, dy, dz, rx, ry, rz, etc.) between ETRS89 and WGS84 are not constant, due to the movement of the Eurasian geophysical plate with respect to WGS84. The differences between both datums can grow by several centimetres a year. Currently they are a couple of decimetres in difference. For many applications, these differences are not relevant. Coordinates or positions in WGS84 have usually been obtained by GPS and this results in an accuracy at the level of several metres. However, satellite positioning techniques continuously improve in accuracy, also without using differential stations. So the differences between the datum's will grow. Note that many nations are using WGS84 to define boundaries nowadays - so WGS84 is relevant.
>  
> In your case and for your application, I do believe you will be fine using ETRS89.
>  
> Cheers,
> Dean


--


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: DHDN / Gauss Krueger to WGS84

Roger Oberholtzer
In reply to this post by Frank Warmerdam
A while back, the following discussion took place here:


> On Thu, 2007-09-20 at 12:06 -0400, Frank Warmerdam wrote:
> Oliver Eichler wrote:
> >> I do have a coordinate in easting/northing [m] from a raster map  using
> >> Gauss Krüger projection and Potsdam datum. Now I would like to get the
> >> lon/lat coordinate on a WGS84 ellipsoid. And vice versa. I would like to
> >> use the proj4 C API not the command line.
> >
> > Ok, further investigations condensed into something like:
> >
> > pjgaukru = pj_init_plus("+init=epsg:31467");
> > pjwgs84 = pj_init_plus("+init=epsg:4326");
> >
> > // easting / northing to lon / lat
> > pt = pj_inv(pt,pjgaukru)
> >
> > //???
> > double z = 0;
> >
> > pj_datum_transform(pjgaukru, pjwgs84, 1, 0, &pt.u, &pt.v, &z);
> >
> > However the result is still several minutes away from the expected
> > coordinate. What do I miss?
>
> Oliver,
>
> How about:
>
> pjgaukru = pj_init_plus("+init=epsg:31467");
> pjwgs84 = pj_init_plus("+init=epsg:4326");
>
> //???
> double z = 0;
>
> pj_datum_transform(pjgaukru, pjwgs84, 1, 0, &pt.u, &pt.v, &z);
>
> Don't forget that the output is pt.u with the longitude in
> radians, and pt.v with the latitude in radians.  The call
> you make to pj_inv() is duplicating work that is done by
> pj_transform() (corrupting really).
>
> I would add that epsg:31467 expands as:
>
> +proj=tmerc +lat_0=0 +lon_0=9 +k=1.000000 +x_0=3500000 +y_0=0 +ellps=bessel
> +datum=potsdam +units=m +no_defs
>
> Note that this definition is using +datum=potsdam which expands to:
>
>    +ellps=bessel +towgs84=606.0,23.0,413.0
>
> This may or may not be the best datum shift parameters for your area of
> work.  You may need to research a better local shift.


I find myself needing the exact same thing. So, I thought I would
implement this in the C API, where I usually do these sorts of things. I
usually use pj_transform() instead of pj_datum_transform(). But as the
recipe uses pj_datum_transform(), I thought I would too.

The problem is that the values I get back from pj_datum_transform() are
infinite values (as expressed by printf). If I use pj_transform() the
locations are incorrect - they are located in central Asia.

I am testing with a sample set of coordinates provided later in the
quoted thread:

> it seems to work. A reference point of:
>
> x = 4459750 m  y = 5448182 m
>
> is converted to
>
> E11.446588 N49.169494


If I use pj_transform(), I get:
 
  21.982946, 48.433278

So, perhaps pj_datum_transform() provides the correct calculation. But
as I get infinite values, I can't tell.

I am running proj 4.7.0 on Linux. It works for all other uses I have.

In addition to following the recipe, above I have also tried specifying
the values more directly as:

toProj = pj_init_plus(
                "+proj=tmerc "                  // Projection
                "+ellps=bessel "                // Spheroid
                "+k=1.0 "                       // Scale factor at central meridian
                "+x_0=3500000 "                 // False easting
                "+y_0=0 "                       // False northing
                "+lon_0=9.0 "                   // Longitude of central meridian
                "+lat_0=0.0 "                   // Latitude of origin
                "+towgs84=606.0,23.0,413.0 "    // Datum
                "+units=m "
                "+no_defs");

fromProj = pj_init_plus(
                "+proj=latlong "
                "+datum=WGS84");

double  le = 4459750, // easting,
        ln = 5448182, // northing,
        la = 0.0;     // altitude;

pj_transform(toProj,
             fromProj,
             1, 0,
             &le, &ln, &la)

LONG  = le / DEGREE_TO_RADIAN;
LAT   = ln / DEGREE_TO_RADIAN;
ALT   = la;


In the real code, all return values are checked, and there are no
errors.

My goal is to convert these values to/from WGS84 latitude and
longitudes.

Any useful suggestions are greatly appreciated.

TIA



Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int +46 10-615 60 20
Mobile: Int +46 70-815 1696
[hidden email]
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: DHDN / Gauss Krueger to WGS84

Roger Oberholtzer
Bad form to reply to my own post, but...

> > I would add that epsg:31467 expands as:
> >
> > +proj=tmerc +lat_0=0 +lon_0=9 +k=1.000000 +x_0=3500000 +y_0=0 +ellps=bessel
> > +datum=potsdam +units=m +no_defs

> > it seems to work. A reference point of:
> >
> > x = 4459750 m  y = 5448182 m
> >
> > is converted to
> >
> > E11.446588 N49.169494
>
>
> If I use pj_transform(), I get:
>  
>   21.982946, 48.433278

I see that cs2cs gives the same incorrect result I get, and not the
expected result:

cs2cs +init=epsg:31467 +to +init=epsg:4326
4459750 5448182
21d58'58.607"E  48d25'59.803"N -15.126


Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int +46 10-615 60 20
Mobile: Int +46 70-815 1696
[hidden email]
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: DHDN / Gauss Krueger to WGS84

peifer
On 30/03/2012 12:23, Roger Oberholtzer wrote:
> I see that cs2cs gives the same incorrect result I get, and not the
> expected result:
>
> cs2cs +init=epsg:31467 +to +init=epsg:4326
> 4459750 5448182
> 21d58'58.607"E  48d25'59.803"N -15.126
>
>

If your x-value starts with a 4, shouldn't it then be GK zone 4 =
epsg:31468 ?

$ echo "4459750 5448182" | cs2cs +init=epsg:31468 +to +init=epsg:4326
11d26'47.703"E  49d10'10.159"N 50.082

Hermann

_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: DHDN / Gauss Krueger to WGS84

Mikael Rittri
In reply to this post by Roger Oberholtzer
Hello Roger,

Actually, I do believe that E 21.982946, N 48.433278 is the correct
result, or at least more correct than E 11.446588, N 49.169494.

Here is how I convinced myself:

Since x = 4459750 m and the False Easting is 3500000,
the point is 4459750 - 3500000 = 959750 m east of the
central meridian which is 9° E.

At the equator, there are about 111120 meters
per degree, so if we were at the equator we would
be 959750 / 111120 = 8.64° east of the central
meridian.  But at the approximate latitude 49° N, the
meridians are closer together by a factor cos(49°),
so we are really about 8.64°/cos(49°) = 13.17° degrees
east of the central meridian, which is 22.17° east
of Greenwich.

This is of course just a rough calculation, ignoring
the changing local scale of the projection etc, but
I think it shows that the longitude should be nearer
22°E than 11°E.

I don't know what's wrong with the original test example.

(For a while, I was thinking it had to do with the axis order,
 since in EPSG:31467, x should be northing and y easting.
 But 4459750 m cannot be a northing here, since it would
 be too far south, somewhere in south Italy.
 So I suppose your test example does use the mathematical
 convention after all, with x as easting and y as northing.)

Best regards,

Mikael Rittri
Carmenta
Sweden
http://www.carmenta.com

-----Original Message-----
From: [hidden email] [mailto:[hidden email]] On Behalf Of Roger Oberholtzer
Sent: Friday, March 30, 2012 12:23 PM
To: PROJ.4 and general Projections Discussions
Subject: Re: [Proj] DHDN / Gauss Krueger to WGS84

Bad form to reply to my own post, but...

> > I would add that epsg:31467 expands as:
> >
> > +proj=tmerc +lat_0=0 +lon_0=9 +k=1.000000 +x_0=3500000 +y_0=0 +ellps=bessel
> > +datum=potsdam +units=m +no_defs

> > it seems to work. A reference point of:
> >
> > x = 4459750 m  y = 5448182 m
> >
> > is converted to
> >
> > E11.446588 N49.169494
>
>
> If I use pj_transform(), I get:
>  
>   21.982946, 48.433278

I see that cs2cs gives the same incorrect result I get, and not the
expected result:

cs2cs +init=epsg:31467 +to +init=epsg:4326
4459750 5448182
21d58'58.607"E  48d25'59.803"N -15.126


Yours sincerely,

Roger Oberholtzer

OPQ Systems / Ramböll RST

Office: Int +46 10-615 60 20
Mobile: Int +46 70-815 1696
[hidden email]
________________________________________

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se


_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: DHDN / Gauss Krueger to WGS84

peifer
On 30/03/2012 13:38, Mikael Rittri wrote:
> Hello Roger,
>
> Actually, I do believe that E 21.982946, N 48.433278 is the correct
> result, or at least more correct than E 11.446588, N 49.169494.
>
> Here is how I convinced myself...

Here is how I convinced myself that the opposite is true:

- DHDN = Deutsches_Hauptdreiecksnetz, a Datum used in Germany, i.e. not
used at E 21.982946
- in a coordinate system based on 3-degree zones, it doesn't make much
sense to have x-values which are 959750 m east of any central meridian
- at school, I learned: if the leading digit of the x-value is 4, than
you are in 3-degree Gauss-Kruger zone 4 (nowadays also known as epsg:31468)
- GK3 zone 4 has a central meridian of 12 degrees East and a false
easting of 4500000m, see also [1]

Given the above, you end up with:

echo "4459750 5448182" | cs2cs -f "%.6f" +init=epsg:31468 +to
+init=epsg:4326
11.446584       49.169489 50.081973

(i.e. some 100+ km north of Munich)

Hermann

[1]
http://upload.wikimedia.org/wikipedia/de/1/12/Gau%C3%9F-Kr%C3%BCger-Raster_Deutschland.png
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
Reply | Threaded
Open this post in threaded view
|

Re: DHDN / Gauss Krueger to WGS84

Mikael Rittri
Hermann,
you are right, of course.

In the original thread, DHDN zone 3 was mentioned,
but the discussion was mainly about the datum shift.

Later in the thread, the test point was given, but without
a zone number. (I suppose all German GIS people know that
the leading digit of the Easting is the zone number.)

Thanks,

Mikael Rittri
Carmenta
Sweden
http://www.carmenta.com

-----Original Message-----
From: Hermann Peifer [mailto:[hidden email]]
Sent: Friday, March 30, 2012 2:10 PM
To: PROJ.4 and general Projections Discussions
Cc: Mikael Rittri
Subject: Re: DHDN / Gauss Krueger to WGS84

On 30/03/2012 13:38, Mikael Rittri wrote:
> Hello Roger,
>
> Actually, I do believe that E 21.982946, N 48.433278 is the correct
> result, or at least more correct than E 11.446588, N 49.169494.
>
> Here is how I convinced myself...

Here is how I convinced myself that the opposite is true:

- DHDN = Deutsches_Hauptdreiecksnetz, a Datum used in Germany, i.e. not
used at E 21.982946
- in a coordinate system based on 3-degree zones, it doesn't make much
sense to have x-values which are 959750 m east of any central meridian
- at school, I learned: if the leading digit of the x-value is 4, than
you are in 3-degree Gauss-Kruger zone 4 (nowadays also known as epsg:31468)
- GK3 zone 4 has a central meridian of 12 degrees East and a false
easting of 4500000m, see also [1]

Given the above, you end up with:

echo "4459750 5448182" | cs2cs -f "%.6f" +init=epsg:31468 +to
+init=epsg:4326
11.446584       49.169489 50.081973

(i.e. some 100+ km north of Munich)

Hermann

[1]
http://upload.wikimedia.org/wikipedia/de/1/12/Gau%C3%9F-Kr%C3%BCger-Raster_Deutschland.png
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj
12