# [Proj] truble to translate coordinates from WGS84 to EPSG:31287

Mikael Rittri Mikael.Rittri at carmenta.com
Mon Nov 1 09:06:00 EST 2010

```Hello Markus,

you wrote:
> And on the the jhlabs site i found under "What is missing" the statement
> "Coordinate system and geodetic datum conversion is missing."
> (http://www.jhlabs.com/java/maps/proj/index.html)
>
> Doing the transformation with the jhlabs-lib would require some additional
> coding for the datum transformation. Something i am not able to do with my
> tiny knowlege in both fields, java and the math behind all that transformations.

An alternative is to do the datum shift by an approximate "direct projection"
from WGS84/long-lat to MGI/Austria Lambert (EPSG:31287).  This is a method where
you would start by attaching the Austria Lambert projection to WGS84 - that
is, to the WRONG datum.  The results will not be correct, of course, so then
you fiddle with the projection parameters until the results are pretty good.

I think many people regard this method as a dirty hack, but the Swedish Land
Survey recommends it for a Swedish CRS, and I have to admit that I like the
method.  Out of curiousity, I tried it for MGI/Austria Lambert.  (Ideally, my
parameter fiddling should be derived from some original survey observations
for the MGI and WGS84 datums, but I used the 7-parameter datum shift instead.
This means that my "direct projection" is an approximation of an approximation,
so it can probably be improved, but not very much I think.)

My result was pretty good. I finally arrived at the following approximation
of MGI/Austria Lambert:

>proj +datum=WGS84 +proj=lcc +lat_1=46.0103424 +lat_2=48.988621 +lat_0=47.5 +lon_0=13.33616275 +x_0=400268.785 +y_0=400057.553

When I tested it on your example points, I got from FWTools 2.4.7:

WGS84 long lat		approx MGI/Austria Lambert, E N	diff from geoland.at
14.2833092 48.3098392	470507.18  490503.02                0.02 m
16.371345  48.211996	625724.63  483601.73			0.07 m
9.747076  47.503042	130056.96  406637.16			0.73 m

(I got the geoland.at results from your first letter,
http://lists.maptools.org/pipermail/proj/2010-October/005454.html )

Since the accuracy of your original 7-parameter datum shift was about 1.5 meters,
the accuracy of my direct projection seems to about as good.

Actually, I think my direct projection stays within 0.1 or 0.2 m difference
from the 7-parameter datum shift. I guess that geoland.at uses a more
sophisticated datum shift, perhaps a grid file, which would explain the
0.73 m difference for the third example point.

Best regards,
Mikael Rittri
Carmenta AB
Sweden
http://www.carmenta.com

-----Original Message-----
From: proj-bounces at lists.maptools.org [mailto:proj-bounces at lists.maptools.org] On Behalf Of Markus Hetzmannseder
Sent: den 28 oktober 2010 15:50
To: PROJ.4 and general Projections Discussions
Subject: Re: [Proj] truble to translate coordinates from WGS84 to EPSG:31287

On Thu, 28 Oct 2010, Paul Kelly wrote:

> On Thu, 28 Oct 2010, Markus Hetzmannseder wrote:
>
>
> The proj command does a simple forward projection and ignores the
> +towgs84 datum transformation parameters. The cs2cs command takes
> these into account to give a more accurate result. If you leave off
> the +towgs84 parameters from the cs2cs command line you will get the
> same result as with the proj command line. It looks to me like the
> JOSM plugin is not doing the datum transformation, only the projection
> (I had a quick glance at
> <http://svn.openstreetmap.org/applications/editors/josm/plugins/epsg31
> 287/src/com/jhlabs/map/proj/LambertConformalConicProjection.java>)
> to confirm this) - but that is certainly not easy to fix.

Jeah, i know, i was coming to the same result myself too. The epsg31287 plugin is using the jhlabs java lib to do all the transformation. And on the the jhlabs site i found under "What is missing" the statement "Coordinate system and geodetic datum conversion is missing."
(http://www.jhlabs.com/java/maps/proj/index.html)

Doing the transformation with the jhlabs-lib would require some additional coding for the datum transformation. Something i am not able to do with my tiny knowlege in both fields, java and the math behind all that transformations.

Another way would be to rewrite the plugin with another calculation lib in behind. Maybe something from http://geotools.org/ could help...

At least we know now where that offset of the current epsg31287 plugin is coming from. I hope it will help the author of the plugin a bit to find a solution.

Markus
_______________________________________________
Proj mailing list
Proj at lists.maptools.org
http://lists.maptools.org/mailman/listinfo/proj
```