
12

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


> 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


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/~warmerdamand watch the world go round  Rush  President OSGeo, http://osgeo.org_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


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


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/~warmerdamand watch the world go round  Rush  President OSGeo, http://osgeo.org_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


>
> 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 georeference 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


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.phpThere 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 NordrheinWestfalen
... Muffendorfer Str. 19  21 D  53177 Bonn
... Email: [hidden email]
... Internet: http://www.lverma.nrw.de_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


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/~warmerdamand watch the world go round  Rush  President OSGeo, http://osgeo.org_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


[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


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 threedimensional 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."
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
Email: [hidden email]
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


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 threedimensional 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 > Email: [hidden email]> > Dean C. Mikkelsen, B.Sc., P.Eng.
Terra ETL Ltd.
Victoria, B.C., Canada
Phone: +1 (250) 3616672
http://www.terraetl.com
Consulting in Geodesy & GIS for the Natural Resources
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


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


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


A while back, the following discussion took place here:
> On Thu, 20070920 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 10615 60 20
Mobile: Int +46 70815 1696
[hidden email]
________________________________________
Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE104 62 Stockholm, Sweden
www.rambollrst.se
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


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 10615 60 20
Mobile: Int +46 70815 1696
[hidden email]
________________________________________
Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE104 62 Stockholm, Sweden
www.rambollrst.se
_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


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 xvalue 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


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.comOriginal 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 10615 60 20
Mobile: Int +46 70815 1696
[hidden email]
________________________________________
Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE104 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


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 3degree zones, it doesn't make much
sense to have xvalues which are 959750 m east of any central meridian
 at school, I learned: if the leading digit of the xvalue is 4, than
you are in 3degree GaussKruger 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%9FKr%C3%BCgerRaster_Deutschland.png_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj


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.comOriginal 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 3degree zones, it doesn't make much
sense to have xvalues which are 959750 m east of any central meridian
 at school, I learned: if the leading digit of the xvalue is 4, than
you are in 3degree GaussKruger 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%9FKr%C3%BCgerRaster_Deutschland.png_______________________________________________
Proj mailing list
[hidden email]
http://lists.maptools.org/mailman/listinfo/proj

12
