ThinkGeo.com    |     Documentation    |     Premium Support

Timbalai RSO Transform Problem

#1

Hi,



I’ve put together a simple datum transformation project designed to validate the conversion from Timbalai RSO to WGS84 Lat/Long.  Unfortunately, I am finding several hundred meters difference between what I get with MapSuite and what I get from Blue Marble.



The Blue Marble result is what I expect based on test points I have received from multiple clients.  A screen shot of the transformation in Blue Marble is in the root of the project directory.



Please can you explain what is going on here?



Additionally, there appears no way to control which transform is applied.  There are actually 5 EPSG valid transforms for this datum.  Is there a way I can pick which one is applied or at least know which one is used?



Regards,

Damian

TimbalaiTransformTest.zip (156 KB)

#2

Hi Damian,



I checked the EPSG 29873 in spatialreference.org/ref/epsg/29873/ and it returns me the proj4 string which equals to ManagedProj4Projection.GetEpsgParametersString(29873). 



However, I also check it in another website cs2cs.mygeodata.eu/ but I got a hundred meter offsets in its proj string like you mentioned:

"+proj=omerc +lat_0=4 +lonc=115 +alpha=53.31582047222222 +k=0.99984 +x_0=590476.87 +y_0=442857.65 +gamma=53.13010236111111 +ellps=evrstSS +towgs84=-533.4,669.2,-52.5,0,0,4.28,9.4 +units=m +no_defs"



So a workaround is we can have a try with the below codes:

 wgsProj.InternalProjectionParametersString = “+proj=omerc +lat_0=4 +lonc=115 +alpha=53.31582047222222 +k=0.99984 +x_0=590476.87 +y_0=442857.65 +gamma=53.13010236111111 +ellps=evrstSS +towgs84=-533.4,669.2,-52.5,0,0,4.28,9.4 +units=m +no_defs”;

Instead of 

wgsProj.InternalProjectionParametersString = ManagedProj4Projection.GetEpsgParametersString(29873)



As for how to pick up 5 epsg from your datum, I think we need to know which area the data is in or if we have the .prj file, we can use the below codes:

wgsProj.InternalProjectionParametersString = UnmanagedProj4Projection.ConvertPrjToProj4(File.ReadAllText(@“xx.prj”))



Hope it helps.

Thanks,

Troy

#3

Hi Troy,



This is very helpful.  I never saw before the ability to supply ‘towgs84’ tag with the shifts I need to use.  This is actually what I meant by there being 5 EPSG transforms for this area.  Essentially, these transforms between CRS have EPGS codes as well as the CRS themselves.  In my case, I want to use transform #1592 found here epsg.io/1592



So, I modify the string as follows simply changing the towgs84 shifts as all other parameters are identical in the definition:

 wgsProj.InternalProjectionParametersString = “+proj=omerc +lat_0=4 +lonc=115 +alpha=53.31582047222222 +k=0.99984 +x_0=590476.87 +y_0=442857.65 +gamma=53.13010236111111 +ellps=evrstSS +towgs84=-678.0,670.0,-48.0,0,0,0,0 +units=m+no_defs”;



However, I still have problem.  The results are closer now, but still ~300m difference.  For reference, my final goal is to get valid transform through to WGS84 UTM 50N (EPSG 32650).  But, I think going to WGS84 first is needed to verify the process.



FYI:  Accidentally did not put expectedPoint in the console writeline statement although the delta x,y values are correct



Thanks,

Damian

#4

Hi Damian,



I did some researches on code #1592 and I got some links:

epsg.io/29849-1592 

spatialreference.org/ref/epsg/29849/proj4/



From the first link we can get its proj4 text: +proj=utm +zone=49 +ellps=evrstSS +towgs84=-678,670,-48,0,0,0,0 +units=m +no_defs 

from the second link we can get: +proj=utm +zone=49 +ellps=evrstSS +units=m +no_defs 



I think #1592 is target to EPSG 29849 and the only differences is there are some difference accuracy on this projection.

Please try the above proj4 and let us know if there are correct.

Thanks,

Troy




#5

Hi Damian,



I did some researches on code #1592 and I got some links:

epsg.io/29849-1592 

spatialreference.org/ref/epsg/29849/proj4/



From the first link we can get its proj4 text: +proj=utm +zone=49 +ellps=evrstSS +towgs84=-678,670,-48,0,0,0,0 +units=m +no_defs 

from the second link we can get: +proj=utm +zone=49 +ellps=evrstSS +units=m +no_defs 



I think #1592 is target to EPSG 29849 and the only differences is there are some difference accuracy on this projection.





Please try the above proj4 and let us know if there are correct.

Thanks,

Troy


#6

Troy,


I am not sure why you are sending me UTM zone CRS.  We already know that my test point is referenced to EPSG #29873.


The transform that is correct is found here. epsg.io/29873-1592


Please provide to me a test project showing that ThinkGeo can apply the correct transformation to the test point as per the attached document.




Regards,

Damian

Timbalai1948_NW_Borneo_RSO_Geodetics.docx (43.4 KB)

#7

Hi Damian, 
  
 Some parameters are necessary, I don’t know more information about “+towgs84”, but I think that the following four parameters are necessary: X-axis rotation, Y-axis rotation, Z-axis rotation and Scale difference. 
  
 So the string for proj4 should be “+proj=omerc +lat_0=4 +lonc=115 +alpha=53.31582047222222 +k=0.99984 +x_0=590476.87 +y_0=442857.65 +gamma=53.13010236111111 +ellps=evrstSS +towgs84=-689.5937,623.84046,-65.93566,0.02331,-1.17094,0.80054,5.88536 +units=m+no_defs”. 
  
 The parameters are referred from georepository.com/transformation_5249/Timbalai-1948-to-WGS-84-5.html. 
  
 I hope it is helpful for you. 
  
 But even if we use these parameters, the result have many differences with your target result. Unlucky we haven’t found other solution to get the target result. We will go on looking for a better solution. 
  
 Regards, 
  
 Don

#8

Don,



This is starting to get out of hand.  We can dance around this all day with different web sites.  If you want to use georepository, then this is the reference to get from Timbalai (29873) to WGS84 (4326) using the transform that I want to employ.



georepository.com/transforma…-84-2.html



And there are in fact 5 valid transforms for the area, 1228, 1592, 1615, 1852 and 5249 (which is the one you just send me)…  See below.







You guys seem to be missing the point that putting in the proj4 projection for the transform I want to employ doesn’t yield the right results.  And further that I do get the right results from other notable tools like Blue Marble.  This seems like a major problem to me.  We do a lot of work in this region and it’s very typical to receive a mix of Timbalai and WGS84 shapes from different resources.  



I need to know that ThinkGeo is going to address this and come up with a solution in a reasonable time-frame.



Regards,

Damian


















#9

Hi Damian,



Sorry we were on the wrong direction before. Our team had a depth debug and it proved a bug as our projection library is a bit old. Now, we have come up a solution for you in ticket system by using  and we will keep tracking on a complete solution. I will update both here and our ticket system if any news.



Sorry again.

Thanks,

Troy