Projection problem from WGS84 Web Mercator (102100) to RD New (28992)

3602
5
07-14-2011 06:42 AM
MahenderRajendran
New Contributor II
I have been trying to reproject the geometry from wgs84 (102100) to RD New(28992). Its working fine but there is an offset of 200 meters from the original location. I am using geometryService.ProjectAsync method for the re-projection. I tried using both WKID and WKT. Also there is 'TOWGS84' parameter missing in the projection definition.But unfortunately I could not find the right parameters for 'TOWGS84' in WKT String.
Any suggestions/Help would be great. Thanks.

WKT string:

PROJCS["RD_New",GEOGCS["GCS_Amersfoort",DATUM["D_Amersfoort",SPHEROID["Bessel_1841",6377397.155,299.1528128]],PRIMEM["Greenwich",0.0],UNIT["Degree",0.0174532925199433]],PROJECTION["Double_Stereographic"],PARAMETER["False_Easting",155000.0],PARAMETER["False_Northing",463000.0],PARAMETER["Central_Meridian",5.38763888888889],PARAMETER["Scale_Factor",0.9999079],PARAMETER["Latitude_Of_Origin",52.15616055555555],UNIT["Meter",1.0]]
0 Kudos
5 Replies
JenniferNery
Esri Regular Contributor
You can use: http://spatialreference.org/ref/epsg/28992/

Are you saying ProjectAsync result is incorrect? If so, can you try to run Fiddler and reproduce the issue outside your Silverlight Application by using the same parameters found in WebForms?
0 Kudos
MahenderRajendran
New Contributor II
You can use:   http://spatialreference.org/ref/epsg/28992/

Are you saying ProjectAsync result is incorrect? If so, can you try to run Fiddler and reproduce the issue outside your Silverlight Application by using the same parameters found in WebForms?


Yes the result produced from ProjectAsync is incorrect.The ESRI wkt string referred in spatialreference.org is not correct(getting negative results for Y coordinates).Further there is no "TOWGS84" parameter in WKT string.But the WKT string mentioned in my first post is working fine except there is an offset of 200 meters.

I also tried using EPSG code 28992:
geometryService.ProjectAsync(graphicsLayer.Graphics.ToList(), new SpatialReference(28992));

Still getting the incorrect result.

Check the attachment from Fiddler debugging.
Result Coordinates: X: 171680 , Y: 483353 (incorrect)
Correct Coordinates:X:171713 , Y:483445
0 Kudos
DominiqueBroux
Esri Frequent Contributor
Are you sure that the result is incorrect?

I tried with a coordinates converter which is not using the ESRI library and I got the same result.
See attached screenshot:
[ATTACH=CONFIG]7816[/ATTACH]

That being said, it doesn't prove that both are right. Where are your results coming from?
0 Kudos
MahenderRajendran
New Contributor II
Are you sure that the result is incorrect?

I tried with a coordinates converter which is not using the ESRI library and I got the same result.
See attached screenshot:
[ATTACH=CONFIG]7816[/ATTACH]

That being said, it doesn't prove that both are right. Where are your results coming from?


I checked the results in ArcGIS desktop. Check the screenshots attached.
In the image '102100_point' ,I have added input XY coordinates with base map having epsg 102100.

In the image '28992_projected_point_without_transformations' , I have added base map having EPSG 102100 without applying transformations to my RD New Data and then added the result XY coordintes (from projectAsync method) . RD New data is not projected properly.Added point is in the correct place based on map data but displaced based on my RD New data.

In the image '28992_projected_point_with_transformations', you can see that my rdnew data has been properly projected with the base map after applying transformations,but added point has been displaced. Check the attachment 'transformation_parameters' for the transformation parameters applied before projection.

Apart from ArcGIS desktop i also checked in an external site. Check the attachment 'external_check'

So my conclusion is that 'TOWGS84' parameter is missing in WKT string of 28992. I tried the parameters used in desktop and did not work neither.
0 Kudos
DominiqueBroux
Esri Frequent Contributor
It seems you are right. There is a shift due to the datum transformation.

Unfortunately, at this time, the geometry service project REST API doesn't support explicitely specifying a datum for transformation.
AFAIK it's planned for version 10.1.

So my conclusion is that 'TOWGS84' parameter is missing in WKT string of 28992.

I don't think that the project REST API takes in care the TOWGS84 parameter. So it would be useless to initialize it.
But I am not sure, you should get better answers to REST API forum
0 Kudos