headers
karel cech | 4 Dec 2006 13:20
Picon

UTM ED50 to ETRS89 datum shift problem

Hi list,
I have a problem with changing datum with cs2cs using 7 parameter
shift from ED50/UTM30 to ETRS89. The result differs a lot from
transformation results made by Carthographic Institute of Valencia
(they work with ESRI and ERMapper)
My test point has following coordinates (ED50/UTM30, EPSG:23030)
720931.9
4376574.85
What I would like to obtain is aproximatly this (ETRS89, EPSG:25830):
720821.51
4376365.31
However, cs2cs gives me
720748.93
4376357.47

The 7 parameters are defined by spanish institutions.

The debug output from cs2cs (proj 4.4.9.):

cs2cs -v +proj=utm +zone=30 +ellps=intl
+towgs84=-131.0320,-100.2510,-163.3540,1.2438,0.0195,1.1436,9.3900
+units=m +to +proj=utm +ellps=GRS80 +zone=30 +units=m -r <<EOF
> 720931.9
> 4376574.85
> EOF
pj_open_lib(proj_def.dat): call
fopen(/usr/local/proj4/share/proj/proj_def.dat) - succeeded
pj_open_lib(proj_def.dat): call
fopen(/usr/local/proj4/share/proj/proj_def.dat) - succeeded
# ---- From Coordinate System ----
(Continue reading)

Permalink | Reply | 668 comments |
headers
José Alberto Gonçalves | 4 Dec 2006 16:43
Picon
Favicon

Re: UTM ED50 to ETRS89 datum shift problem

It seems that your input is not correct. You must input one point per 
line, with x and y separated by space or tab.
I didn't check the command line.

Jose' Gonçalves

karel cech wrote:

> Hi list,
> I have a problem with changing datum with cs2cs using 7 parameter
> shift from ED50/UTM30 to ETRS89. The result differs a lot from
> transformation results made by Carthographic Institute of Valencia
> (they work with ESRI and ERMapper)
> My test point has following coordinates (ED50/UTM30, EPSG:23030)
> 720931.9
> 4376574.85
> What I would like to obtain is aproximatly this (ETRS89, EPSG:25830):
> 720821.51
> 4376365.31
> However, cs2cs gives me
> 720748.93
> 4376357.47
>
> The 7 parameters are defined by spanish institutions.
>
> The debug output from cs2cs (proj 4.4.9.):
>
> cs2cs -v +proj=utm +zone=30 +ellps=intl
> +towgs84=-131.0320,-100.2510,-163.3540,1.2438,0.0195,1.1436,9.3900
> +units=m +to +proj=utm +ellps=GRS80 +zone=30 +units=m -r <<EOF
(Continue reading)

Permalink | Reply | 1 comment |
headers
karel cech | 4 Dec 2006 18:32
Picon

Re: UTM ED50 to ETRS89 datum shift problem

Jose,
thanks a lot, what a mistake...
Now I have only 5m error in northing and 2m in easting which is OK for
my purpose I think.
720827.53 4376363.70

On 12/4/06, José Alberto Gonçalves <jagoncal <at> fc.up.pt> wrote:
> It seems that your input is not correct. You must input one point per
> line, with x and y separated by space or tab.
> I didn't check the command line.
>
> Jose' Gonçalves
>
>
>
>
> karel cech wrote:
>
> > Hi list,
> > I have a problem with changing datum with cs2cs using 7 parameter
> > shift from ED50/UTM30 to ETRS89. The result differs a lot from
> > transformation results made by Carthographic Institute of Valencia
> > (they work with ESRI and ERMapper)
> > My test point has following coordinates (ED50/UTM30, EPSG:23030)
> > 720931.9
> > 4376574.85
> > What I would like to obtain is aproximatly this (ETRS89, EPSG:25830):
> > 720821.51
> > 4376365.31
> > However, cs2cs gives me
(Continue reading)

Permalink | Reply | 0 comments |
headers
Oscar van Vlijmen | 4 Dec 2006 23:14
Picon

Re: UTM ED50 to ETRS89 datum shift problem

> From: "karel cech"
> Date: Mon, 4 Dec 2006 13:20:37 +0100
> Subject: [Proj] UTM ED50 to ETRS89 datum shift problem
> 
> Hi list,
> I have a problem with changing datum with cs2cs using 7 parameter
> shift from ED50/UTM30 to ETRS89. The result differs a lot from
> transformation results made by Carthographic Institute of Valencia
> (they work with ESRI and ERMapper)
> My test point has following coordinates (ED50/UTM30, EPSG:23030)
> 720931.9
> 4376574.85
> What I would like to obtain is aproximatly this (ETRS89, EPSG:25830):
> 720821.51
> 4376365.31
> However, cs2cs gives me
> 720748.93
> 4376357.47
> 
> The 7 parameters are defined by spanish institutions.
> 
> The debug output from cs2cs (proj 4.4.9.):
> 
> cs2cs -v +proj=utm +zone=30 +ellps=intl
> +towgs84=-131.0320,-100.2510,-163.3540,1.2438,0.0195,1.1436,9.3900
> +units=m +to +proj=utm +ellps=GRS80 +zone=30 +units=m -r <<EOF

....

It is possible that your transformation parameters were for the coordinate
(Continue reading)

Permalink | Reply | 668 comments |
headers
karel cech | 5 Dec 2006 11:38
Picon

Re: UTM ED50 to ETRS89 datum shift problem

On 12/4/06, Oscar van Vlijmen <ovv <at> hetnet.nl> wrote:
> > From: "karel cech"
> > Date: Mon, 4 Dec 2006 13:20:37 +0100
> > Subject: [Proj] UTM ED50 to ETRS89 datum shift problem
> >
> > Hi list,
> > I have a problem with changing datum with cs2cs using 7 parameter
> > shift from ED50/UTM30 to ETRS89. The result differs a lot from
> > transformation results made by Carthographic Institute of Valencia
> > (they work with ESRI and ERMapper)
> > My test point has following coordinates (ED50/UTM30, EPSG:23030)
> > 720931.9
> > 4376574.85
> > What I would like to obtain is aproximatly this (ETRS89, EPSG:25830):
> > 720821.51
> > 4376365.31
> > However, cs2cs gives me
> > 720748.93
> > 4376357.47
> >
> > The 7 parameters are defined by spanish institutions.
> >
> > The debug output from cs2cs (proj 4.4.9.):
> >
> > cs2cs -v +proj=utm +zone=30 +ellps=intl
> > +towgs84=-131.0320,-100.2510,-163.3540,1.2438,0.0195,1.1436,9.3900
> > +units=m +to +proj=utm +ellps=GRS80 +zone=30 +units=m -r <<EOF
>
> ....
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Mikael Rittri | 5 Dec 2006 13:53
Picon

Insignificant difference between Swiss and Hungarian Oblique Mercator?

Hello,
I think I have implemented the Hungary EOV projection, which is a
generalization
of the Swiss Oblique Mercator (+proj=somerc).  In the Hungarian version,
you
can specify a normal parallel, distinct from the central one.  The
_normal_ 
parallel gives the center of the first step of the double projection
(ellipsoid -> sphere), while the _central_ parallel gives the center 
of the second step (sphere -> oblique cylinder).  

I've modified the code of the PROJ.4 somerc, to cover the Hungarian
usage as well, but I am rather surprised: the effect of having 
normal parallel != central parallel is about 0.01 millimeters.  

Yet, to quote Molnar and Timar,
http://www.fomi.hu/honlap/magyar/szaklap/2002/03/mar3.pdf ,
"its normal parallel slightly but intentionally differs ..." [from the
central one].

But I cannot understand the intention, if the difference in projected
coordinates 
is so small.  (And I don't read Hungarian; only the abstract is in
English).

I've read on this list that PROJ.4 users do use +proj=somerc for
Hungary,
but I thought the approximation would be worse.  Just to rule out the 
possibility that I have made a silly mistake: could anyone confirm that
the approximation error is about 0.01 millimeters?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Sergey Spiridonov | 5 Dec 2006 13:00

patch: move geod functions to proj library and create API to use it


Hi,

Patch in attachment can be applied to proj-4.5.0. To apply the patch:

tar xzf proj-4.5.0.tgz
cd proj-4.5.0
patch -p1 <../proj-4.5.0-geod_api.patch

Following functions were added:

GEODESIC_T *GEOD_init(int, char **, GEODESIC_T *geodesic);
GEODESIC_T *GEOD_init_plus(const char *args, GEODESIC_T *geodesic);

They work the same way as proj_init and proj_init_plus, except that they
accept additional parameter GEODESIC_T *geodesic.

If geodesic is 0, memory for GEODESIC_T will be allocated and pointer to
allocated memory will be returned.

Functions geodetic_for, geod_inv, geod_pre are changed to accept pointer
to the GEODESIC_T. All global variables are moved to this structure.

Functions geod_for, geod_inv, geod_pre become members of the proj library.

I also include changes to Makefile.in, but may be it is better to
regenerate it again (or even exclude from distribution as it is
generated file).

Following 2 functions are not included into the patch, they just make
(Continue reading)

Permalink | Reply | 2 comments |
headers
Frank Warmerdam | 5 Dec 2006 18:17
Picon
Favicon
Gravatar

Re: patch: move geod functions to proj library and create API to use it

Sergey Spiridonov wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hi,
> 
> Patch in attachment can be applied to proj-4.5.0. To apply the patch:

Sergey,

I'm interested in applying this change, but I'd appreciate if you could
file the patch and description in bugzilla so it will be available when
I get to this issue.

Best regards,
--

-- 
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up   | Frank Warmerdam, warmerdam <at> pobox.com
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
Proj <at> lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
Permalink | Reply | 1 comment |
headers
Sergey Spiridonov | 5 Dec 2006 17:52

Re: patch: move geod functions to proj library and create API to use it


Hi, Frank

Frank Warmerdam wrote:

> I'm interested in applying this change, but I'd appreciate if you could
> file the patch and description in bugzilla so it will be available when
> I get to this issue.

http://bugzilla.remotesensing.org/show_bug.cgi?id=1378

--
Best regards, Sergey Spiridonov
Permalink | Reply | 0 comments |
headers
Oscar van Vlijmen | 6 Dec 2006 14:00
Picon

Re: Insignificant difference between Swiss and Hungarian Oblique Mercator?

I didn't receive Mikael Rittri's message with the subject:
  [Proj] Insignificant difference between Swiss and
  Hungarian Oblique Mercator?
dated 2006-12-05
But I found it lurking in the archives. Of course, I could have accidentally
deleted the received message myself. In case others have missed it too: the
complete message is copied below.

As for the Hungarian EOV projection: I haven't seen any official test points
yet, so it is not clear if what I am doing is correct.
But the near-official formulae from the Department of Cartography and
Geoinformatics, Eötvös University, Budapest
<http://lazarus.elte.hu/gb/geodez/geodind.htm>
give for a
lat = 48; lon = 22;
an "x", "y" of:
299283.5538, 870209.6285 m

Monár Gábor & Timár Gábor give in an article to be found at:
<http://www.fomi.hu/internet/magyar/szaklap/2002/03/mar3.pdf>
an approximation for EOV with an oblique Mercator.
If I understand the parameters correctly:
ellipsoid: GRS67
lat0 = "47d 08m 39.8174s"; lonc = "19d 02m 54.8584s";
alfac = 90; gamma = 90;
k0 = 0.99993; x0 = -9370549.28432; y0 = 200000.00114;
set no_offset flag
omerc(lat,lon,lat0,lonc,alfac,gamma,k0,x0,y0);
Result: x = 870209.5387; y = 299283.5505 m
This differs by 9.0 cm and 3.3 mm with the correct values.
(Continue reading)

Permalink | Reply | 501 comments |

Gmane