Hello,
I joined the mailing list because I noticed that the PROJ.4 library uses approximate formulas for the 7 parameter coordinate transformation defined by +towgs84 (technical details: The elements of the rotation matrix are the rotation angles instead of the product of sines and cosines of the angles). For really small rotation angles this gives the same result, but not for larger rotations. For my current application I want to transform a map in QGIS with 1 mm accuracy. However, the approximation causes an error of 4 cm. Since PROJ.4 normally gives results within 0.1 mm accuracy, I did not expect such approximation. What can I do to help to fix this? Regards, Jochem |
Jochem,
If you want to abandon the small-angle approximation and use sines and cosines, you must then define an order for the three rotation matrices (about X, about Y, and about Z). Different matrix orders give different answers. What's your preferred order and why? Noel Noel Zinn, Principal, Hydrometronics LLC +1-832-539-1472 (office), +1-281-221-0051 (cell) [hidden email] (email) http://www.hydrometronics.com (website) -----Original Message----- From: Jochem Sent: Wednesday, March 22, 2017 4:41 PM To: [hidden email] Subject: [Proj] +towgs84 approximation error Hello, I joined the mailing list because I noticed that the PROJ.4 library uses approximate formulas for the 7 parameter coordinate transformation defined by +towgs84 (technical details: The elements of the rotation matrix are the rotation angles instead of the product of sines and cosines of the angles). For really small rotation angles this gives the same result, but not for larger rotations. For my current application I want to transform a map in QGIS with 1 mm accuracy. However, the approximation causes an error of 4 cm. Since PROJ.4 normally gives results within 0.1 mm accuracy, I did not expect such approximation. What can I do to help to fix this? Regards, Jochem -- View this message in context: http://osgeo-org.1560.x6.nabble.com/towgs84-approximation-error-tp5313738.html Sent from the PROJ.4 mailing list archive at Nabble.com. _______________________________________________ Proj mailing list [hidden email] http://lists.maptools.org/mailman/listinfo/proj _______________________________________________ Proj mailing list [hidden email] http://lists.maptools.org/mailman/listinfo/proj |
In reply to this post by Jochem
Hello Jochem
The 7 parameter coordinate transformations are for datum shifts, which are themselves approximative operations by nature. They have stochastic error unrelated to the Proj.4 accuracy, much greater than the sine approximation. For example the "NAD27 to WGS 84 (4)" transformation over USA (EPSG:1173) has an accuracy of 10 metres. So in this context I wonder what would be the purpose of aiming for an "accuracy" of 0.1 mm. It can not be a positional accuracy (in the geodetic sense) at least, but maybe the intend was something else? Martin Le 22/03/2017 à 22:41, Jochem a écrit : > Hello, > > I joined the mailing list because I noticed that the PROJ.4 library uses > approximate formulas for the 7 parameter coordinate transformation defined > by +towgs84 (technical details: The elements of the rotation matrix are the > rotation angles instead of the product of sines and cosines of the angles). > For really small rotation angles this gives the same result, but not for > larger rotations. > > For my current application I want to transform a map in QGIS with 1 mm > accuracy. However, the approximation causes an error of 4 cm. Since PROJ.4 > normally gives results within 0.1 mm accuracy, I did not expect such > approximation. > > What can I do to help to fix this? > > Regards, Jochem _______________________________________________ Proj mailing list [hidden email] http://lists.maptools.org/mailman/listinfo/proj |
In reply to this post by Jochem
Hello Jochem, Perhaps this: https://github.com/OSGeo/proj.4/blob/master/src/PJ_helmert.c may be of interest to you. And although it is still poorly documented and probably not available in currently distributed versions of qgis, any comments you may offer on the functionality, with and without using the +approx flag will be much appreciated 2017-03-22 22:41 GMT+01:00 Jochem <[hidden email]>: Hello, _______________________________________________ Proj mailing list [hidden email] http://lists.maptools.org/mailman/listinfo/proj |
In reply to this post by Martin Desruisseaux-3
Hi Jochem, if I understood well you need a method to transform your coordinates from one system to another. 7 parameters transformation (or Bursa-Wolf) is a geodetic coordinates transformation method, so the first question you must answer is what type of coordinates do you have on both systems and you must describe these systems. A second issue that arises is the accuracy. Martin already explained you that 7 param. method gives transformations with errors of even >10 m big. So big errors are expected when we deal with datum (ellipsoids) that have parameters with big differences between them. There is a confuse also, if I got the point, on the proj.4 calculation rounding errors that you say are 0.1 mm and the standard deviation of your transformed coordinates which you say are 4.5 cm. In turn we can't help you unless you explain clearly : "what you have" and "what you need". regards Stefanos Beligiannis From: Martin Desruisseaux <[hidden email]> To: [hidden email] Sent: Thursday, March 23, 2017 12:33 AM Subject: Re: [Proj] +towgs84 approximation error Hello Jochem The 7 parameter coordinate transformations are for datum shifts, which are themselves approximative operations by nature. They have stochastic error unrelated to the Proj.4 accuracy, much greater than the sine approximation. For example the "NAD27 to WGS 84 (4)" transformation over USA (EPSG:1173) has an accuracy of 10 metres. So in this context I wonder what would be the purpose of aiming for an "accuracy" of 0.1 mm. It can not be a positional accuracy (in the geodetic sense) at least, but maybe the intend was something else? Martin Le 22/03/2017 à 22:41, Jochem a écrit : > Hello, > > I joined the mailing list because I noticed that the PROJ.4 library uses > approximate formulas for the 7 parameter coordinate transformation defined > by +towgs84 (technical details: The elements of the rotation matrix are the > rotation angles instead of the product of sines and cosines of the angles). > For really small rotation angles this gives the same result, but not for > larger rotations. > > For my current application I want to transform a map in QGIS with 1 mm > accuracy. However, the approximation causes an error of 4 cm. Since PROJ.4 > normally gives results within 0.1 mm accuracy, I did not expect such > approximation. > > What can I do to help to fix this? > > Regards, Jochem _______________________________________________ Proj mailing list [hidden email] http://lists.maptools.org/mailman/listinfo/proj _______________________________________________ Proj mailing list [hidden email] http://lists.maptools.org/mailman/listinfo/proj |
In reply to this post by Martin Desruisseaux-3
Hi Martin,
WGS84 is just a hub for many users. I will transform data from frame A via WGS84 to frame B. The transformation from A to B should have 1 mm (not 0.1 mm) accuracy for me, since the coordinates are of 1 cm accuracy. Moreover, 7 parameter transformations are not always stochastic, e.g. the transformation between the Dutch national grid and ETRS89 (=WGS84 +/- 1 m) is by definition exact since the Dutch national grid is defined as the transformation from ETRS89. Furthermore, world wide geodetic positional accuracy in ITRF (=WGS84 +/- 0.0001 m) is possible well below the accuracy of the 4 cm error I am experiencing. I think these are 3 reasons why the approximation is not good enough and should be improved. Regards, Jochem |
In reply to this post by Noel Zinn (cc)
Hi Noel,
My preference is Rz Ry Rx because this is how it is mentioned in my geodesy text books. This could be different in other countries (like positive and negative the rotation direction). The order Rz Ry Rx is also the order used by EPSG which is the source of most of the parameters used by PROJ.4. I think that is a good reason to keep to that order. Reference: http://www.iogp.org/pubs/373-07-2.pdf (page 134) Regards, Jochem |
Is that the rotation order or the matrix multiplication order? :-). Whatever the order, the resultant direction cosine matrix remains the same, an orthogonal rotation matrix.
Sent from Cliff Mugnier's iPhone > On Mar 22, 2017, at 8:16 PM, Jochem <[hidden email]> wrote: > > Hi Noel, > > My preference is Rz Ry Rx because this is how it is mentioned in my geodesy > text books. This could be different in other countries (like positive and > negative the rotation direction). The order Rz Ry Rx is also the order used > by EPSG which is the source of most of the parameters used by PROJ.4. I > think that is a good reason to keep to that order. > > Reference: > http://www.iogp.org/pubs/373-07-2.pdf > <http://www.iogp.org/pubs/373-07-2.pdf> (page 134) > > Regards, Jochem > > > > -- > View this message in context: http://osgeo-org.1560.x6.nabble.com/towgs84-approximation-error-tp5313738p5313764.html > Sent from the PROJ.4 mailing list archive at Nabble.com. > _______________________________________________ > Proj mailing list > [hidden email] > http://lists.maptools.org/mailman/listinfo/proj Proj mailing list [hidden email] http://lists.maptools.org/mailman/listinfo/proj |
In reply to this post by Stefanos Beligiannis
Hi Stefanos,
I have coordinates in an old national grid and a new national grid. Both grids have TM projections on the international Hayfort ellipsoid. Both grids have 7 parameter transformations to WGS84 defined by the government but not published in EPSG. I want to do: cs2cs +init=mygrids:old +to +init=mygrids:new -f %.4f <old_coords.txt >new_coords.txt What I need is exactly what I explained in my first email: a 7 parameter transformation without approximation error of 4 cm (this error is a bias, not a standard deviation) in the formulas. Regards, Jochem |
In reply to this post by Clifford J Mugnier
Noel, That is matrix multiplication order, like explained the reference. So, the rotation order is X, Y, Z.
Jochem |
Hi Jochem, I was going to ask why you weren't using the RDNAPTRANS utility (available from https://www.kadaster.nl/transformatie-van-coordinaten), but I see that you are one of the authors of that utility :-) Regards, Nick. On Thu, Mar 23, 2017 at 2:37 PM, Jochem <[hidden email]> wrote: Noel, That is matrix multiplication order, like explained the reference. So, _______________________________________________ Proj mailing list [hidden email] http://lists.maptools.org/mailman/listinfo/proj |
In reply to this post by Thomas Knudsen
Hi Thomas,
Thanks. Should I compile this to an exe or an other type of file? Where should I put that file in order to use it in QGIS? Regards, Jochem |
In reply to this post by Jochem
How many coordinate pairs? For that level of desired accuracy you're going to need more than 100 points. Is that reasonable?
Sent from Cliff Mugnier's iPhone > On Mar 22, 2017, at 8:34 PM, Jochem <[hidden email]> wrote: > > Hi Stefanos, > > I have coordinates in an old national grid and a new national grid. Both > grids have TM projections on the international Hayfort ellipsoid. Both grids > have 7 parameter transformations to WGS84 defined by the government but not > published in EPSG. I want to do: > > cs2cs +init=mygrids:old +to +init=mygrids:new -f %.4f <old_coords.txt >> new_coords.txt > > What I need is exactly what I explained in my first email: a 7 parameter > transformation without approximation error of 4 cm (this error is a bias, > not a standard deviation) in the formulas. > > Regards, Jochem > > > > > -- > View this message in context: http://osgeo-org.1560.x6.nabble.com/towgs84-approximation-error-tp5313738p5313766.html > Sent from the PROJ.4 mailing list archive at Nabble.com. > _______________________________________________ > Proj mailing list > [hidden email] > http://lists.maptools.org/mailman/listinfo/proj Proj mailing list [hidden email] http://lists.maptools.org/mailman/listinfo/proj |
In reply to this post by Nick Mein
Hi Nick,
I am not in the Netherlands at the moment. This is for another country. I would like to make it possible for them to use Proj.4 instead of writing a dedicated transformation program. Regards, Jochem |
In reply to this post by Jochem
Hi Jochem, this is more clear : 1. Usually these parameters are defined by the government by LSM and their (the parameters) computations are based on some CPs of the National HARN network with coordinates calculated on both systems. This means they enclose the national grid internal errors plus the least square methods calculation errors. In turn it is a big luck for you that you have only up to 4.5cm error. 2. To my opinion, If you want better accuracy you must re-measure with big accuracy the coordinates of those (or at least, as many as possible) common points you have on the old Hayford datum, on WGS84 with GPS static Measurements and then define new "local" 7 parameters to transform the coordinates you have, and ignore the government for this area. 3. I had the same with you problem on Riyadh Airport (Ain Al Abd datum) and I solved it like above. I find the problem very interesting and I want to kindly give me feedback how you solved it. many thanks Stefanos From: Jochem <[hidden email]> To: [hidden email] Sent: Thursday, March 23, 2017 3:35 AM Subject: Re: [Proj] +towgs84 approximation error Hi Stefanos, I have coordinates in an old national grid and a new national grid. Both grids have TM projections on the international Hayfort ellipsoid. Both grids have 7 parameter transformations to WGS84 defined by the government but not published in EPSG. I want to do: cs2cs +init=mygrids:old +to +init=mygrids:new -f %.4f <old_coords.txt >new_coords.txt What I need is exactly what I explained in my first email: a 7 parameter transformation without approximation error of 4 cm (this error is a bias, not a standard deviation) in the formulas. Regards, Jochem -- View this message in context: http://osgeo-org.1560.x6.nabble.com/towgs84-approximation-error-tp5313738p5313766.html Sent from the PROJ.4 mailing list archive at Nabble.com. _______________________________________________ Proj mailing list [hidden email] http://lists.maptools.org/mailman/listinfo/proj _______________________________________________ Proj mailing list [hidden email] http://lists.maptools.org/mailman/listinfo/proj |
In reply to this post by Jochem
Hi Jochem QGIS runs Python you need a C compiler for Thomas program. regards Stefanos From: Jochem <[hidden email]> To: [hidden email] Sent: Thursday, March 23, 2017 3:53 AM Subject: Re: [Proj] +towgs84 approximation error Hi Thomas, Thanks. Should I compile this to an exe or an other type of file? Where should I put that file in order to use it in QGIS? Regards, Jochem -- View this message in context: http://osgeo-org.1560.x6.nabble.com/towgs84-approximation-error-tp5313738p5313769.html Sent from the PROJ.4 mailing list archive at Nabble.com. _______________________________________________ Proj mailing list [hidden email] http://lists.maptools.org/mailman/listinfo/proj _______________________________________________ Proj mailing list [hidden email] http://lists.maptools.org/mailman/listinfo/proj |
In reply to this post by Clifford J Mugnier
Cliff,
The transformation has been estimated by performing static GPS observations on about 12 points of the old triangulation frame. Ofcourse these parameters are not at 1 mm precise but more like a few cm. However, these parameters have been in use for some time now. Therefore these parameters are conventional* parameters and I need to keep to that convention within 1 mm. I do not know the number of points to be transformed, the entire digital map of a small country (probably a few million). *) Van der Marel, 2016 page 33-34 Regards, Jochem |
In reply to this post by Stefanos Beligiannis
Hi Stefanos,
You are still completely misunderstanding my problem. The responsible agency already did these measurements. And the measurements are ok. They also computed the 7 parameters. These are ok too. I checked the least-squares adjustment. The problem is that the Proj.4 formulas are wrong. Wrong in the sense that they give different results from transformation with other software. I used several software packages and the differences between them were 0.1 to a few mm. The only one that was 4 cm different was Proj.4. However I don't want to use one of the other software packages as these can only transform points and not vector maps like QGIS. Ragards, Jochem |
Hi Jochem,
A few comments: > The problem is that the Proj.4 formulas are wrong. Wrong in the > sense that they give different results from transformation with other > software. I used several software packages and the differences between > them > were 0.1 to a few mm. The only one that was 4 cm different was Proj.4. You need to demonstrate this with some actual data and an example of what you are doing. Please recreate the problem with a call to cs2cs. Until we see some results it is only going to be guesswork from our side. > Thanks. Should I compile this to an exe or an other type of file? Where > should I put that file in order to use it in QGIS? It is a bit more convoluted to use a development version of PROJ.4 with QGIS. It is certainly possible if you know what you are doing, but I assume that you don't Since QGIS is a rather complicated setup. Basically you need to first build a recent development version of PROJ.4, and then compile QGIS with PROJ.4 as one of the depending libraries. Look towards the QGIS documentation for a proper write up of the process. > This is for another country. I > would like to make it possible for them to use Proj.4 instead of writing a > dedicated transformation program. This is a very sensible approach, one that I hope many other countries will adapt in the coming years. We are doing the same thing in Denmark. Which is also why we are expanding the geodetic capabilities of PROJ.4 at the moment. The progress can be followed on GitHub where development is on-going, and some background can be found in the archives of this list. Best regards, Kristian > -----Oprindelig meddelelse----- > Fra: [hidden email] [mailto:proj- > [hidden email]] På vegne af Jochem > Sendt: 23. marts 2017 03:38 > Til: [hidden email] > Emne: Re: [Proj] +towgs84 approximation error > > Hi Stefanos, > > You are still completely misunderstanding my problem. The responsible > agency > already did these measurements. And the measurements are ok. They also > computed the 7 parameters. These are ok too. I checked the least-squares > adjustment. > > However I don't want to use one of the other software packages as these > can > only transform points and not vector maps like QGIS. > > Ragards, Jochem > > > > -- > View this message in context: http://osgeo- > org.1560.x6.nabble.com/towgs84-approximation-error- > tp5313738p5313778.html > Sent from the PROJ.4 mailing list archive at Nabble.com. > _______________________________________________ > Proj mailing list > [hidden email] > http://lists.maptools.org/mailman/listinfo/proj Proj mailing list [hidden email] http://lists.maptools.org/mailman/listinfo/proj |
In reply to this post by Stefanos Beligiannis
Oh so sorry Jochem
Thank you for the explanations. I use my own software and I had never realized proj. I am sorry to hear a so usefull program like proj has these bugs. Thank you for informing me. Regards Stefanos
_______________________________________________ Proj mailing list [hidden email] http://lists.maptools.org/mailman/listinfo/proj |
Free forum by Nabble | Edit this page |