Re: [postgis-users] New algorithms on the spheroid: intersecting lines and minimum distance point-line. Current software error assesment.

[Дорофей Пролесковский]

Hi,

Fundamental issue is that the world is 4D and geodetic computation is 2D.

You can get a result that's nice mathematically, but the idea of "carry out
the calculations in full on the ellipsoid and thus be able to forget about
the projected CRS, and leave them purely for aesthetic purposes" comes from
a terrible inexperience of the domain. Great circle lines are barely
compensating for 2.5D out of 4D.

The issues you're not considering at least are:
 - continental drift makes sure your GPS coordinates stays the same in
Greenwich, but everywhere else things move in the scale of meters now. you
usually want to pin your data to the continental plate, you need local
CRSes for that.
 - there is terrain, and it is more complex than just a height in every
spot - you have caves, and depending on where you put the center of 3D CRS
a thing can be a cave or not.
 - "up" is not pointing to the center of earth, but goes along the vector
of gravity, which - surprise - is curved.
 - what is a line between two points in 3D space depends heavily on what
you're doing. you're splitting a land, it's fence length on the surface of
land (which is not the same as the great circle for which you gave your
"perfect" solution). You're setting up a wireless link, it's a 3D straight
line with elevations considered. Both will be called "distance" and both
can be between some lon-lat coordinates.

All of the above combined give a lot more error than 1%. To compensate for
each of the above you need to apply cognitive effort to get what exactly you
are doing. Without that effort, a more precise formula will be just like
showing 15 signs after a comma on an app that shows the closest bar "to be
more exact", just ignorance in the field of metrology and types of errors.

Otherwise it's nice to have a new math method, but please don't throw
claims like "it deprecates the need for projected CRS" .


сб, 31 июл. 2021 г. в 19:52, José Carlos Martínez :

> Hi,
>
> I was not expecting that answer and less to hear about calculations on the
> sphere when we are talking about geodesy!.
>
> The comparison between the spheroidal (local sphere) and spherical
> intersection has already been made in the article. We did it because some
> software uses this approach. It is important for us to check each software
> methodology in order to be able to rigorously compare the results.
>
> The spherical method is very easy and trivial because it is just using
> spherical trigonometry but the errors commited and very large as you can
> check in our paper, so please keep it without exposing this functionality
> to the end user because it is a very rude approach, and if so the end user
> must be warned about that. By the way, the name of the source code in
> postgis about geodetic calculations (lwgeodetic) could be confusing because
> geodetic coordinates use a spheroid not a sphere, and geodetic calculations
> should be done using geodesics lines.
>
> You talked about 1% of distance errors saying that its *not that wrong*.
> Umm...do not know how to answer that...I mean 1% its incredible wrong, even
> 1 per thousands its not ok for many tasks.
>
> Maybe 1% could be ok for those users who use postgis to make thematic maps
> in a small scales but anything else.
>
> I am referring to the maps listed in annexes 1 and 2 of inspire in Europe,
> or similar in other countries: cadastral maps, transport networks, etc. on
> a large scale, so it means that the error tolerance in only a few
> centimeters but the distances of the segments can be long, so no spherical
> method can be used, or even a local projected transformation, at least
> without knowing the error comitted (error that you do not know with postgis
> or other app right now) in advance.
>
> I agree with you about that to build a full set of spatial operators
> working on the spheroid is a much more complicated task that just an
> intersection of geodesics, but with the two proposed algorithm (geodesic
> intersection and minimun distance from a point to a geodesic)  you can
> already do many things, even just involving linear layers. Do you really
> need to build a full topology geodetic library in order to incorporate in
> postgis the two funtions I am talking about?
>
> So, this methodoly give you:
>
> 1.- Exact solution
>
> 2.- Assesment of the commited errors of other methods (spherical,
> projected CRS, etc.).
>
> 3.- Working with the full globe, no matter the distance for the precision.
>
> Cheers
>
> José
>
>
> El 28/07/2021 a las 18:54, Paul Ramsey escribió:
>
> This is very interesting, but from a practical point of view the problems
> around doing intersections on the spheroid are not to do with the
> difficulty of calculating spheroidal intersection points, but the
> difficulty in programming things that are relatively simple in cartesian
> (R2) space in spherical space (S2), like "is this point in this ring",
> because the question of "what does this ring enclose" is quite different in
> S2 than 

Re: [postgis-users] New algorithms on the spheroid: intersecting lines and minimum distance point-line. Current software error assesment.

[José]

Jose Carlos,Buena respuesta. Tienes toda la razón. 
Un abrazo.
Jose

Enviado desde mi iPhone

> El 31 jul 2021, a las 18:53, José Carlos Martínez  
> escribió:
> 
> 
> Hi,
> 
> I was not expecting that answer and less to hear about calculations on the 
> sphere when we are talking about geodesy!.
> 
> The comparison between the spheroidal (local sphere) and spherical 
> intersection has already been made in the article. We did it because some 
> software uses this approach. It is important for us to check each software 
> methodology in order to be able to rigorously compare the results.
> 
> The spherical method is very easy and trivial because it is just using 
> spherical trigonometry but the errors commited and very large as you can 
> check in our paper, so please keep it without exposing this functionality to 
> the end user because it is a very rude approach, and if so the end user must 
> be warned about that. By the way, the name of the source code in postgis 
> about geodetic calculations (lwgeodetic) could be confusing because geodetic 
> coordinates use a spheroid not a sphere, and geodetic calculations should be 
> done using geodesics lines.
> 
> You talked about 1% of distance errors saying that its *not that wrong*. 
> Umm...do not know how to answer that...I mean 1% its incredible wrong, even 1 
> per thousands its not ok for many tasks.
> 
> Maybe 1% could be ok for those users who use postgis to make thematic maps in 
> a small scales but anything else. 
> 
> I am referring to the maps listed in annexes 1 and 2 of inspire in Europe, or 
> similar in other countries: cadastral maps, transport networks, etc. on a 
> large scale, so it means that the error tolerance in only a few centimeters 
> but the distances of the segments can be long, so no spherical method can be 
> used, or even a local projected transformation, at least without knowing the 
> error comitted (error that you do not know with postgis or other app right 
> now) in advance.
> 
> I agree with you about that to build a full set of spatial operators working 
> on the spheroid is a much more complicated task that just an intersection of 
> geodesics, but with the two proposed algorithm (geodesic intersection and 
> minimun distance from a point to a geodesic)  you can already do many things, 
> even just involving linear layers. Do you really need to build a full 
> topology geodetic library in order to incorporate in postgis the two funtions 
> I am talking about?
> 
> So, this methodoly give you:
> 
> 1.- Exact solution
> 
> 2.- Assesment of the commited errors of other methods (spherical, projected 
> CRS, etc.). 
> 
> 3.- Working with the full globe, no matter the distance for the precision.
> 
> Cheers
> 
> José
> 
> 
> 
> El 28/07/2021 a las 18:54, Paul Ramsey escribió:
>> This is very interesting, but from a practical point of view the problems 
>> around doing intersections on the spheroid are not to do with the difficulty 
>> of calculating spheroidal intersection points, but the difficulty in 
>> programming things that are relatively simple in cartesian (R2) space in 
>> spherical space (S2), like "is this point in this ring", because the 
>> question of "what does this ring enclose" is quite different in S2 than in 
>> R2. IE, the complexity of the problem does not reside in the spheroidal 
>> geometry but in the spherical topology. Which is not to say that it cannot 
>> be done, Google S2 has done a number of constructive geometry functions in 
>> spherical space, but it's not just a matter of getting the right 
>> intersection points.
>> 
>> I would be interested in direct comparisons between spheroidal and spherical 
>> intersection, rather than comparisons with "whatever the heck these tools 
>> use under the covers", which your survey shows is "quite a wide variety of 
>> approaches". 
>> 
>> Unfortunately although PostGIS has spherical intersection internally 
>> (hilariously, I calculate it here [1] but never even let it out of the 
>> function) it is not exposed to the end user. You could use Google S2 [2] to 
>> generate spherical intersection points though, and compare those to 
>> spheroidal. 
>> 
>> The reason I ask is because comparison of spherical and spheroidal 
>> *distances* never yield particularly large differences, always under 1%. 
>> Now, spherical distances are not *right*, but they are also *not that wrong* 
>> which is presumably why tools like S2 have eschewed finding spheroidal 
>> intersections. Under the covers you'll find that the PostGIS distance 
>> functions use spherical calculations to find the two points that are closest 
>> between two geometries, and only then calculate the spheroidal distance 
>> between those points.
>> 
>> Thanks for sharing your research,
>> Paul
>> 
>> [1] https://github.com/postgis/postgis/blob/main/liblwgeom/lwgeodetic.c#L3596
>> [2] http://s2geometry.io/
>> 
>> 
>> On Tue, Jul 27, 2021 at 9:34 AM José Carlos Martínez  
>> wrote:
>>> Hi list,
>>> 

Re: [postgis-users] New algorithms on the spheroid: intersecting lines and minimum distance point-line. Current software error assesment.

[José Carlos Martínez]

Hi,

I was not expecting that answer and less to hear about calculations on 
the sphere when we are talking about geodesy!.


The comparison between the spheroidal (local sphere) and spherical 
intersection has already been made in the article. We did it because 
some software uses this approach. It is important for us to check each 
software methodology in order to be able to rigorously compare the results.


The spherical method is very easy and trivial because it is just using 
spherical trigonometry but the errors commited and very large as you can 
check in our paper, so please keep it without exposing this 
functionality to the end user because it is a very rude approach, and if 
so the end user must be warned about that. By the way, the name of the 
source code in postgis about geodetic calculations (lwgeodetic) could be 
confusing because geodetic coordinates use a spheroid not a sphere, and 
geodetic calculations should be done using geodesics lines.


You talked about 1% of distance errors saying that its *not that wrong*. 
Umm...do not know how to answer that...I mean 1% its incredible wrong, 
even 1 per thousands its not ok for many tasks.


Maybe 1% could be ok for those users who use postgis to make thematic 
maps in a small scales but anything else.


I am referring to the maps listed in annexes 1 and 2 of inspire in 
Europe, or similar in other countries: cadastral maps, transport 
networks, etc. on a large scale, so it means that the error tolerance in 
only a few centimeters but the distances of the segments can be long, so 
no spherical method can be used, or even a local projected 
transformation, at least without knowing the error comitted (error that 
you do not know with postgis or other app right now) in advance.


I agree with you about that to build a full set of spatial operators 
working on the spheroid is a much more complicated task that just an 
intersection of geodesics, but with the two proposed algorithm (geodesic 
intersection and minimun distance from a point to a geodesic)  you can 
already do many things, even just involving linear layers. Do you really 
need to build a full topology geodetic library in order to incorporate 
in postgis the two funtions I am talking about?


So, this methodoly give you:

1.- Exact solution

2.- Assesment of the commited errors of other methods (spherical, 
projected CRS, etc.).


3.- Working with the full globe, no matter the distance for the precision.

Cheers

José


El 28/07/2021 a las 18:54, Paul Ramsey escribió:
This is very interesting, but from a practical point of view the 
problems around doing intersections on the spheroid are not to do with 
the difficulty of calculating spheroidal intersection points, but the 
difficulty in programming things that are relatively simple in 
cartesian (R2) space in spherical space (S2), like "is this point in 
this ring", because the question of "what does this ring enclose" is 
quite different in S2 than in R2. IE, the complexity of the problem 
does not reside in the spheroidal geometry but in the spherical 
topology. Which is not to say that it cannot be done, Google S2 has 
done a number of constructive geometry functions in spherical space, 
but it's not just a matter of getting the right intersection points.


I would be interested in direct comparisons between spheroidal and 
spherical intersection, rather than comparisons with "whatever the 
heck these tools use under the covers", which your survey shows is 
"quite a wide variety of approaches".


Unfortunately although PostGIS has spherical intersection internally 
(hilariously, I calculate it here [1] but never even let it out of the 
function) it is not exposed to the end user. You could use Google S2 
[2] to generate spherical intersection points though, and compare 
those to spheroidal.


The reason I ask is because comparison of spherical and spheroidal 
*distances* never yield particularly large differences, always under 
1%. Now, spherical distances are not *right*, but they are also *not 
that wrong* which is presumably why tools like S2 have eschewed 
finding spheroidal intersections. Under the covers you'll find that 
the PostGIS distance functions use spherical calculations to find the 
two points that are closest between two geometries, and only then 
calculate the spheroidal distance between those points.


Thanks for sharing your research,
Paul

[1] 
https://github.com/postgis/postgis/blob/main/liblwgeom/lwgeodetic.c#L3596 


[2] http://s2geometry.io/ 


On Tue, Jul 27, 2021 at 9:34 AM José Carlos Martínez 
mailto:jomar...@cgf.upv.es>> wrote:


Hi list,

I want to share our last research about gemetric operations on the
spheroid [1]

Considering two segments defined by 2 points each one over the
spheroid.
We want to get the intersection point defined by these two segments.

Several points to 

Re: [postgis-users] New algorithms on the spheroid: intersecting lines and minimum distance point-line. Current software error assesment.

[Paul Ramsey]

This is very interesting, but from a practical point of view the problems
around doing intersections on the spheroid are not to do with the
difficulty of calculating spheroidal intersection points, but the
difficulty in programming things that are relatively simple in cartesian
(R2) space in spherical space (S2), like "is this point in this ring",
because the question of "what does this ring enclose" is quite different in
S2 than in R2. IE, the complexity of the problem does not reside in the
spheroidal geometry but in the spherical topology. Which is not to say that
it cannot be done, Google S2 has done a number of constructive geometry
functions in spherical space, but it's not just a matter of getting the
right intersection points.

I would be interested in direct comparisons between spheroidal and
spherical intersection, rather than comparisons with "whatever the heck
these tools use under the covers", which your survey shows is "quite a wide
variety of approaches".

Unfortunately although PostGIS has spherical intersection internally
(hilariously, I calculate it here [1] but never even let it out of the
function) it is not exposed to the end user. You could use Google S2 [2] to
generate spherical intersection points though, and compare those to
spheroidal.

The reason I ask is because comparison of spherical and spheroidal
*distances* never yield particularly large differences, always under 1%.
Now, spherical distances are not *right*, but they are also *not that
wrong* which is presumably why tools like S2 have eschewed finding
spheroidal intersections. Under the covers you'll find that the PostGIS
distance functions use spherical calculations to find the two points that
are closest between two geometries, and only then calculate the spheroidal
distance between those points.

Thanks for sharing your research,
Paul

[1]
https://github.com/postgis/postgis/blob/main/liblwgeom/lwgeodetic.c#L3596
[2] http://s2geometry.io/


On Tue, Jul 27, 2021 at 9:34 AM José Carlos Martínez 
wrote:

> Hi list,
>
> I want to share our last research about gemetric operations on the
> spheroid [1]
>
> Considering two segments defined by 2 points each one over the spheroid.
> We want to get the intersection point defined by these two segments.
>
> Several points to note:
> 1.- We could not find any software (Oracle Spatial, ArcGIS, PostGIS,
> Google Apis) that performs this calculation on the ellipsoid: some use
> projected CRS, others just use a local sphere.
> 2.- The error comitted by these software is unknown.  And I go further,
> these unknown errors could be greater than the cartographic precision of
> my geo data? If so, all my geo spatial analysis could be wrong.
> 3.- We designed a new algorithm of fast convergence working on the
> spheroid. We can get the exact intersection point, therefore we can
> asses the error from the current software solutions.
> 4.- Example: working with segments around 50km length, the error is
> around 3 meters (PostGIS, ArcGIS). Table 4 from paper [2] shows the
> large error commited by Oracle Spatial, ArcGIS, and even PostGIS with
> local projected CRS (st_intersection with geography).
> 5.- This proposed algorithm is implemented as a test in PostGIS, Java
> and Maxima.
>
>
> Finally, mention that, in a normal computer, about 20,000 intersections
> per second have been obtained. Perhaps, now is the time to migrate
> certain geospatial libraries such as JTS (GEOS), GDAL, etc. so that they
> carry out the calculations in full on the ellipsoid and thus be able to
> forget about the projected CRS, and leave them purely for aesthetic
> purposes.
>
> I will be proud of helping the PostGIS or the JTS team to incorporate
> these geometric operations on the ellipsoid (could be the first spatial
> BDD or geospatial library to do that).
>
>
> Cheers,
>
> José
>
>
> All the information, source code, etc. here.
> [1]
>
> https://cartosig.webs.upv.es/2021/07/27/geodesic-intersection-proposed-algorithm-and-error-assessment-of-current-software/
>
> [2] https://www.mdpi.com/2076-3417/11/11/5129
>
> Martínez-Llario JC, Baselga S, Coll E. Accurate Algorithms for Spatial
> Operations on the Spheroid in a Spatial Database Management System.
> Applied Sciences. 2021; 11(11):5129. https://doi.org/10.3390/app5129
>
> [3] https://link.springer.com/article/10.1007/s11200-017-1020-z
>
> Baselga, S., Martínez-Llario, J.C. Intersection and point-to-line
> solutions for geodesics on the ellipsoid. Stud Geophys Geod 62, 353–363
> (2018). https://doi.org/10.1007/s11200-017-1020-z
>
> [4] https://github.com/jomarlla/geodesicSpatialOperators
>
>
> --
> ---
> José Carlos Martínez Llario
> http://www.upv.es/ficha-personal/jomarlla
> https://cartosig.webs.upv.es
> Producción Cartográfica y SIG.
> Dpto. Ingeniería Cartográfica.
> Univ. Politécnica de Valencia.
> ---
>
> ___
> postgis-users mailing list
> 

[postgis-users] New algorithms on the spheroid: intersecting lines and minimum distance point-line. Current software error assesment.

[José Carlos Martínez]

Hi list,

I want to share our last research about gemetric operations on the 
spheroid [1]


Considering two segments defined by 2 points each one over the spheroid.
We want to get the intersection point defined by these two segments.

Several points to note:
1.- We could not find any software (Oracle Spatial, ArcGIS, PostGIS, 
Google Apis) that performs this calculation on the ellipsoid: some use 
projected CRS, others just use a local sphere.
2.- The error comitted by these software is unknown.  And I go further, 
these unknown errors could be greater than the cartographic precision of 
my geo data? If so, all my geo spatial analysis could be wrong.
3.- We designed a new algorithm of fast convergence working on the 
spheroid. We can get the exact intersection point, therefore we can 
asses the error from the current software solutions.
4.- Example: working with segments around 50km length, the error is 
around 3 meters (PostGIS, ArcGIS). Table 4 from paper [2] shows the 
large error commited by Oracle Spatial, ArcGIS, and even PostGIS with 
local projected CRS (st_intersection with geography).
5.- This proposed algorithm is implemented as a test in PostGIS, Java 
and Maxima.



Finally, mention that, in a normal computer, about 20,000 intersections 
per second have been obtained. Perhaps, now is the time to migrate 
certain geospatial libraries such as JTS (GEOS), GDAL, etc. so that they 
carry out the calculations in full on the ellipsoid and thus be able to 
forget about the projected CRS, and leave them purely for aesthetic 
purposes.


I will be proud of helping the PostGIS or the JTS team to incorporate 
these geometric operations on the ellipsoid (could be the first spatial 
BDD or geospatial library to do that).



Cheers,

José


All the information, source code, etc. here.
[1] 
https://cartosig.webs.upv.es/2021/07/27/geodesic-intersection-proposed-algorithm-and-error-assessment-of-current-software/


[2] https://www.mdpi.com/2076-3417/11/11/5129

Martínez-Llario JC, Baselga S, Coll E. Accurate Algorithms for Spatial 
Operations on the Spheroid in a Spatial Database Management System. 
Applied Sciences. 2021; 11(11):5129. https://doi.org/10.3390/app5129


[3] https://link.springer.com/article/10.1007/s11200-017-1020-z

Baselga, S., Martínez-Llario, J.C. Intersection and point-to-line 
solutions for geodesics on the ellipsoid. Stud Geophys Geod 62, 353–363 
(2018). https://doi.org/10.1007/s11200-017-1020-z


[4] https://github.com/jomarlla/geodesicSpatialOperators


--
---
José Carlos Martínez Llario
http://www.upv.es/ficha-personal/jomarlla
https://cartosig.webs.upv.es
Producción Cartográfica y SIG.
Dpto. Ingeniería Cartográfica.
Univ. Politécnica de Valencia.
---

___
postgis-users mailing list
postgis-users@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/postgis-users