is there a need for subj? i implemented very accurate direct and inverse geodetic problem routines (as well as geocentric (X, Y, Z) to geodetic (B, L, H) conversion) i used bessel's method to derive the formulas 6 iterations for both direct and inverse routines is enough to converge to full double precision (16 digits) however the formulas themselves provide 9 significant digits that is 1cm accuracy regardless of range (i.e. range = 1m..20000km) to get acceptable accuracy, say, 2 iterations is enough (or even 1) however there are several other aspects uncovered (area and perimeter, projections, etc.) -- Pavel
On Thu, Aug 27, 2009 at 3:55 PM, DE<satan66613@yandex.ru> wrote:
is there a need for subj?
i implemented very accurate direct and inverse geodetic problem routines (as well as geocentric (X, Y, Z) to geodetic (B, L, H) conversion) i used bessel's method to derive the formulas 6 iterations for both direct and inverse routines is enough to converge to full double precision (16 digits) however the formulas themselves provide 9 significant digits that is 1cm accuracy regardless of range (i.e. range = 1m..20000km) to get acceptable accuracy, say, 2 iterations is enough (or even 1)
however there are several other aspects uncovered (area and perimeter, projections, etc.)
Do you have plans to support WGS84? What about Vincenty? --Michael Fawcett
Michael Fawcett wrote:
On Thu, Aug 27, 2009 at 3:55 PM, DE<satan66613@yandex.ru> wrote:
i implemented very accurate direct and inverse geodetic problem routines (as well as geocentric (X, Y, Z) to geodetic (B, L, H) conversion) i used bessel's method to derive the formulas 6 iterations for both direct and inverse routines is enough to converge to full double precision (16 digits) however the formulas themselves provide 9 significant digits that is 1cm accuracy regardless of range (i.e. range = 1m..20000km) to get acceptable accuracy, say, 2 iterations is enough (or even 1)
Do you mean transformations or projections? Our library GGL (Generic Geometry Library), aimed for Boost, has (about 100) projections (converted from Proj4). But proj4 datum transformations are not yet converted. So it might be useful to see if your transformations would fit into our library. There were already questions about transformations.
By the way: GGL has an own mailing list which can be found here: http://lists.osgeo.org/mailman/listinfo/ggl, a wiki and ticket system which be found here: http://trac.osgeo.org/ggl/ . Sources are at boost (Preview 4): https://svn.boost.org/svn/boost/sandbox/ggl/ and the latest version is still hosted at Geodan SVN (interested people can have access; it will be also moved to Boost sandbox in ~ october).
however there are several other aspects uncovered (area and perimeter, projections, etc.)
Do you have plans to support WGS84? What about Vincenty?
--Michael Fawcett
GGL has Vincenty distance calculations but you probably mean transformations here? Regards, Barend
On Fri, Aug 28, 2009 at 4:38 AM, Barend Gehrels<barend@geodan.nl> wrote:
Michael Fawcett wrote:
Do you have plans to support WGS84? What about Vincenty?
GGL has Vincenty distance calculations but you probably mean transformations here?
I meant distance as well as "destination point from a start point, bearing, and distance". We currently use ESRI for all of our GIS needs, but GGL looks like it can start slowly becoming a replacement for certain areas of our work. One thing that I haven't seen in either library is offsetting a polyline (linestring). Something like this: http://resources.esri.com/help/9.3/ArcGISEngine/arcobjects/esriGeometry/esri... The reason I ask is because ESRI has a nice little note in their documentation: "This [sic] results produced by this method are sensitive to large offset distances, particularly when the offset distance is larger than the length of the segments in the reference geometry. The remove self intersecting arcs feature is particularly problematic when extremely large offsets are involved. " And, indeed, that is the case. The results start to go nonsensical once the offset distance is larger than the length of the segments in the input polyline. I'm hoping to give Boost.Polygon a try soon, as well as GGL. --Michael Fawcett
One thing that I haven't seen in either library is offsetting a polyline (linestring). Something like this:
http://resources.esri.com/help/9.3/ArcGISEngine/arcobjects/esriGeometry/esri...
I see, interesting. I'm working on a buffer which is flexible in the sense that the buffer distance of left and right can be different, and can be dependent on e.g. a property (such that it changes on the fly). This offsetting is not the same but related, so I can see if we can combine things there. Regards, Barend
on 28.08.2009 at 12:38 Barend Gehrels wrote :
Do you mean transformations or projections? Our library GGL (Generic Geometry Library), aimed for Boost, has (about 100) projections (converted from Proj4). But proj4 datum transformations are not yet converted. So it might be useful to see if your transformations would fit into our library. There were already questions about transformations. i meant both but i implemented only transformation from cartesian to geodetic (XYZ->latitude,longitude,geodetic altitude) and back (which is trivial) i can provide source if you need it
GGL has Vincenty distance calculations but you probably mean transformations here? distance calc from start(lat,long) to end(lat,long) - this is the inverse geodetic problem i also implemented direct geodetic problem: start(lat,long)+distance+azimuth->end(lat,long)
-- Pavel
on 28.08.2009 at 1:15 Michael Fawcett wrote :
Do you have plans to support WGS84? What about Vincenty? any system that operates on ellipsoid can be suuported actually it is a PE-90 implementation (Parameters of the Earth 1990) however the parameters of ellipsoids of PE-90 andwgs-84 are equal +-tolerance in the end you can define your own constants (except pi)
vincenty is another bessel derived method it is actually very ancient (and less accurate than mine) however i borrowed some ideas from there -- Pavel
On Fri, Aug 28, 2009 at 10:56 AM, DE<satan66613@yandex.ru> wrote:
on 28.08.2009 at 1:15 Michael Fawcett wrote :
Do you have plans to support WGS84? What about Vincenty? any system that operates on ellipsoid can be suuported actually it is a PE-90 implementation (Parameters of the Earth 1990) however the parameters of ellipsoids of PE-90 andwgs-84 are equal +-tolerance in the end you can define your own constants (except pi)
vincenty is another bessel derived method it is actually very ancient (and less accurate than mine) however i borrowed some ideas from there
Well, I'm certainly interested. Can you prove yours is more accurate? --Michael Fawcett
on 28.08.2009 at 19:17 Michael Fawcett wrote :
Well, I'm certainly interested. Can you prove yours is more accurate? well, will you believe my word?
i don't know about other implementations but the implementation (vincenty) that i saw truncates the series to the order 6 say (don't remeber exactly) while i save some extra terms (say of order 8) i also compared this solution to a higher order solution (which provides ~12 significant digits but which is overweighted with coeffs) if you are interested i can post a paper of formulas' derivation also there is another approach (to direct problem at least) whole thing is to evaluate an elliptic integral while i do the series expansion (to build inverse routine later) one can directly evaluate the integral with one of special function evaluation techniques (which are widely available, e.g. in numeric recipies) i didn't try this (no time) and can not say if it is more accurate or faster (however it might be) -- Pavel
participants (3)
-
Barend Gehrels -
DE -
Michael Fawcett