[Proj] Netherlands RD (28992) to UTM Zone 32 (3044) produces shifted coordinates

Jan Hartmann j.l.h.hartmann at uva.nl
Tue Jul 30 05:58:20 EST 2013


It could be that MapInfo/Oracle do not use the 7 parameter Helmert 
formula, as used by PROJ, but a grid shift file. The small size of the 
deviations make this very probable. Until recently there was no usable 
grid shift available for PROJ, but the Dutch Topographical Service is 
working on a grid shift file in gsb-format. Nothing has been made public 
as yet, but  I'll ask them and let you know.

By the way, this grid shift file works only within the Netherlands. It 
will give false results if you try to align coordinates in the 
Netherlands and Germany.

Jan

On 30-7-2013 12:27, Jelmer Baas wrote:
>
> Milo, Jan,
>
> Thanks for the suggestions so far. I tried to rule out the NL->DE step 
> by first going to WGS84.
>
> Even this transformation doesn’t go the same as Oracle/MapInfo:
>
> Point        135745.924    517131.216
>
> Oracle  5.10275163084204   52.6413240233221
>
> MapInfo 5.102751           52.641323
>
> PostGis 5.10274900325229   52.6413367842089
>
> PostGi2 5.10274907007772   52.6413367898401
>
> DLL 4   5.10274904569186   52.6413366577093
>
> DLL 3   5.102749003361     52.6413367848006
>
> DLL 2   5.10274903201512   52.6413367357724
>
> DLL 1   5.10274900325279   52.6413367843563
>
> DLL ORG 5.10274909884125   52.6413367414033
>
> I tried these projection strings:
>
> +proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 
> +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel 
> +towgs84=565.417,50.3319,465.552,-0.398957,0.343988,-1.8774,4.0725 
> +units=m +no_defs <>
>
> +proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 
> +k=0.999908 +x_0=155000 +y_0=463000 +ellps=bessel 
> +towgs84=565.417,50.3319,465.552,-0.398957,0.343988,-1.8774,4.0725 
> +units=m +no_defs  no_defs <>
>
> +proj=sterea +lat_0=52.156160556      +lon_0=5.387638889 +k=0.9999079 
> +x_0=155000 +y_0=463000 
> +towgs84=565.417,50.3319,465.552,-0.398957,0.343988,-1.8774,4.0725 
> +ellps=bessel +units=m +no_defs  no_defs <>
>
> +proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 
> +k=0.999908 +x_0=155000 +y_0=463000 +ellps=bessel  +units=m 
> +towgs84=565.04,49.91,465.84,-0.409394387439237,0.359705195614311,-1.86849100035057,4.0772 
> +no_defs +to +proj=latlong +datum=WGS84
>
> +proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 
> +k=0.999908 +x_0=155000 +y_0=463000 +ellps=bessel +units=m 
> +towgs84=565.2369,50.0087,465.658,-0.406857330322398,0.350732676542563,-1.8703473836068,4.0812 
> +no_defs <>
>
> +proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 
> +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel 
> +towgs84=565.04,49.91,465.84,-1.9848,1.7439,-9.0587,4.0772 +units=m 
> +no_defs
>
> Met vriendelijke groet,
>
> Jelmer Baas
>
> Speer IT B.V.
>
> *From:*proj-bounces at lists.maptools.org 
> [mailto:proj-bounces at lists.maptools.org] *On Behalf Of *Milo van der 
> Linden (gmail)
> *Sent:* Tuesday, July 30, 2013 11:57
> *To:* PROJ.4 and general Projections Discussions
> *Subject:* Re: [Proj] Netherlands RD (28992) to UTM Zone 32 (3044) 
> produces shifted coordinates
>
> Hello Jelmer,
>
> 1. I would strongly advice to transform everything to wgs84 first.
>
> 2. wgs84 and etrs89 are based upon different spheroids/datums. 
> Transforming from wgs84 TO etrs89 will not be correct if your etrs89 
> definition does not have +towgs84 defined. And by default I believe it 
> isn't. Take a look at this ticket: 
> http://trac.osgeo.org/proj/ticket/15 and see if it is of any help.
>
> So, what I would do is:
>
> epsg:28992 -> wgs84 (visual check) -> etrs89
>
> Good luck!
>
> 2013/7/30 Jelmer Baas <baas at speerit.nl <mailto:baas at speerit.nl>>
>
> Hello,
>
> For a new project we need to convert coordinates from EPSG 28992 to 
> EPSG 3044 with MapInfo, Oracle AND a few Proj.4 programs (PostGIS, a 
> custom DLL, Proj4js). The problem we are having is that we're seeing 
> some shifted coordinates.
>
> First test point (in the Netherlands)
>
> Origin               135745.924           517131.216
>
> Proj4js              236345.39474983042   5839505.550959114
>
> Postgis(1)           236345.390264227     5839505.55017783
>
> Postgis(2)           236345.394817119     5839505.55055913
>
> MapInfo              236345.47            5839504.058
>
> CS2CSN               236345.39            5839505.55
>
> DLL old(4)            236345.396465174     5839505.54496813
>
> DLL new(3)           236345.390259674     5839505.55009311
>
> Oracle               236345.49107424      5839504.12246656
>
> Test point (in Germany)
>
> Origin              254870.45            415123.56
>
> MapInfo             350265.960           5731670.259
>
> Postgis(1)          350263.4072329       5731667.880
>
> Postgis(2)           350263.4132521       5731667.880
>
> DLL new(3)           350263.407243136     5731667.88019826
>
> DLL old(4)           350263.403514925     5731667.88565864
>
> Oracle(5)           350265.967728329     5731670.33312477
>
> CS2CS                350263.41            5731667.88 43.92     cs2cs 
> +init=EPSG:28992 +to +init=EPSG:3044
>
> It seems MapInfo and Oracle more-or-less agree, as do all Proj.4-based 
> products. I don’t know which are “right”, meaning I also don’t know 
> which ones are wrong – let alone find the fault.
>
> Hopefully someone can help me with this problem, or at least point me 
> in the right direction.
>
> (1): "+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 
> +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel 
> +towgs84=565.417,50.3319,465.552,-0.398957,0.343988,-1.8774,4.0725 
> +units=m +no_defs "
>
> (2) Another server where I updated the spatial_ref_system: 
> "+proj=sterea +lat_0=52.15616055555555 +lon_0=5.38763888888889 
> +k=0.9999079 +x_0=155000 +y_0=463000 +ellps=bessel +units=m 
> +towgs84=565.2369,50.0087,465.658,-0.406857330322398,0.350732676542563,-1.8703473836068,4.0812 
> +no_defs no_defs"
>
> (3) A custom built DLL for usage in VB6. "+proj=sterea 
> +lat_0=52.15616055555555 +lon_0=5.38763888888889 +k=0.999908 
> +x_0=155000 +y_0=463000 +ellps=bessel +units=m 
> +towgs84=565.2369,50.0087,465.658,-0.406857330322398,0.350732676542563,-1.8703473836068,4.0812 
> +no_defs <>"
>
> (4) Same DLL. “+proj=sterea +lat_0=52.15616055555555 
> +lon_0=5.38763888888889 +k=0.9999079 +x_0=155000 +y_0=463000 
> +ellps=bessel 
> +towgs84=565.417,50.3319,465.552,-0.398957,0.343988,-1.8774,4.0725 
> +units=m +no_defs <>”
>
> (5)select sdo_cs.transform(SDO_GEOMETRY('POINT(254870.45 415123.56)', 
> 90112),25832)  from dual;
>
> (5b) The Oracle definition contains some  tags I don’t see anywhere in 
> Proj.4 (like the Bessel 1841 part):
>
> PROJCS["Netherlands National System", GEOGCS [ "Netherlands Bessel", 
> DATUM ["Netherlands Bessel", SPHEROID ["Bessel 1841", 6377397.155, 
> 299.1528128]], PRIMEM [ "Greenwich", 0.000000 ], UNIT ["Decimal 
> Degree", 0.01745329251994330]], PROJECTION ["Stereographic"], 
> PARAMETER ["Scale_Factor", 0.999908], PARAMETER ["Central_Meridian", 
> 5.387639], PARAMETER ["Latitude_Of_Origin", 52.156161], PARAMETER 
> ["False_Easting", 155000.000000], PARAMETER ["False_Northing", 
> 463000.000000], UNIT ["Meter", 1.000000000000]]
>
> A side note is that transformation via my DLL doesn’t work properly 
> (i.e., coordinates are shifted tens of meters), unless I **first** 
> transform to WGS84 and then to 3044. I assume this is caused by an 
> easy-to-fix error, but I don’t know what that is.
>
> P.S.: PostGIS, Proj4JS and my epsg file are all up-to-date.
>
> Thanks for any help,
>
> With kind regards,
>
> Jelmer Baas
>
>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org <mailto:Proj at lists.maptools.org>
> http://lists.maptools.org/mailman/listinfo/proj
>
>
> _______________________________________________
> Proj mailing list
> Proj at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/proj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/proj/attachments/20130730/ab3660f2/attachment-0001.htm 


More information about the Proj mailing list