<div dir="ltr"><div style="overflow-wrap: break-word;">Hi,</div><div style="overflow-wrap: break-word;"><br style="overflow-wrap: break-word;"></div><div style="overflow-wrap: break-word;">Fundamental issue is that the world is 4D and geodetic computation is 2D. </div><div style="overflow-wrap: break-word;"><br style="overflow-wrap: break-word;"></div><div style="overflow-wrap: break-word;">You can get a result that's nice mathematically, but the idea of "<span style="overflow-wrap: break-word;">carry out the calculations in full on the ellipsoid and thus be able to </span><span style="overflow-wrap: break-word;">forget about the projected CRS, and leave them purely for aesthetic </span><span style="overflow-wrap: break-word;">purposes</span><span style="overflow-wrap: break-word;">" comes from a terrible inexperience of the domain. Great circle lines are barely compensating for 2.5D out of 4D.</span></div><div style="overflow-wrap: break-word;"><span style="overflow-wrap: break-word;"><br style="overflow-wrap: break-word;"></span></div><div style="overflow-wrap: break-word;"><span style="overflow-wrap: break-word;">The issues you're not considering at least are:</span></div><div style="overflow-wrap: break-word;"><span style="overflow-wrap: break-word;"> - 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.</span></div><div style="overflow-wrap: break-word;"><span style="overflow-wrap: break-word;"> - 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.<br style="overflow-wrap: break-word;"> - "up" is not pointing to the center of earth, but goes along the vector of gravity, which - surprise - is curved. </span></div><div style="overflow-wrap: break-word;"> - 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.</div><div style="overflow-wrap: break-word;"><br style="overflow-wrap: break-word;"></div><div style="overflow-wrap: break-word;">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 <span style="overflow-wrap: break-word;">exactly</span><span style="overflow-wrap: break-word;"> 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.</span></div><div style="overflow-wrap: break-word;"><span style="overflow-wrap: break-word;"><br style="overflow-wrap: break-word;"></span></div><div style="overflow-wrap: break-word;"><span style="overflow-wrap: break-word;">Otherwise it's nice to have a new math method, but please don't throw claims like "it deprecates the need for projected CRS" .</span></div><br class="gmail-Apple-interchange-newline"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">сб, 31 июл. 2021 г. в 19:52, José Carlos Martínez <<a href="mailto:jomarlla@cgf.upv.es">jomarlla@cgf.upv.es</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<p>Hi,</p>
<p>I was not expecting that answer and less to hear about
calculations on the sphere when we are talking about geodesy!.<br>
</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p>Maybe 1% could be ok for those users who use postgis to make
thematic maps in a small scales but anything else. <br>
</p>
<p>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.<br>
</p>
<p>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?<br>
</p>
<p>So, this methodoly give you:</p>
<p>1.- Exact solution<br>
</p>
<p>2.- Assesment of the commited errors of other methods (spherical,
projected CRS, etc.). <br>
</p>
<p>3.- Working with the full globe, no matter the distance for the
precision.</p>
<p>Cheers</p>
<p>José<br>
</p>
<p><br>
</p>
<div>El 28/07/2021 a las 18:54, Paul Ramsey
escribió:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>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.<br>
</div>
<div><br>
</div>
<div>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". <br>
</div>
<div><br>
</div>
<div>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. <br>
</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Thanks for sharing your research,</div>
<div>Paul<br>
</div>
<div><br>
</div>
<div>[1] <a href="https://github.com/postgis/postgis/blob/main/liblwgeom/lwgeodetic.c#L3596" target="_blank">https://github.com/postgis/postgis/blob/main/liblwgeom/lwgeodetic.c#L3596</a><br>
[2] <a href="http://s2geometry.io/" target="_blank">http://s2geometry.io/</a></div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, Jul 27, 2021 at 9:34
AM José Carlos Martínez <<a href="mailto:jomarlla@cgf.upv.es" target="_blank">jomarlla@cgf.upv.es</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi
list,<br>
<br>
I want to share our last research about gemetric operations on
the <br>
spheroid [1]<br>
<br>
Considering two segments defined by 2 points each one over the
spheroid.<br>
We want to get the intersection point defined by these two
segments.<br>
<br>
Several points to note:<br>
1.- We could not find any software (Oracle Spatial, ArcGIS,
PostGIS, <br>
Google Apis) that performs this calculation on the ellipsoid:
some use <br>
projected CRS, others just use a local sphere.<br>
2.- The error comitted by these software is unknown. And I go
further, <br>
these unknown errors could be greater than the cartographic
precision of <br>
my geo data? If so, all my geo spatial analysis could be
wrong.<br>
3.- We designed a new algorithm of fast convergence working on
the <br>
spheroid. We can get the exact intersection point, therefore
we can <br>
asses the error from the current software solutions.<br>
4.- Example: working with segments around 50km length, the
error is <br>
around 3 meters (PostGIS, ArcGIS). Table 4 from paper [2]
shows the <br>
large error commited by Oracle Spatial, ArcGIS, and even
PostGIS with <br>
local projected CRS (st_intersection with geography).<br>
5.- This proposed algorithm is implemented as a test in
PostGIS, Java <br>
and Maxima.<br>
<br>
<br>
Finally, mention that, in a normal computer, about 20,000
intersections <br>
per second have been obtained. Perhaps, now is the time to
migrate <br>
certain geospatial libraries such as JTS (GEOS), GDAL, etc. so
that they <br>
carry out the calculations in full on the ellipsoid and thus
be able to <br>
forget about the projected CRS, and leave them purely for
aesthetic <br>
purposes.<br>
<br>
I will be proud of helping the PostGIS or the JTS team to
incorporate <br>
these geometric operations on the ellipsoid (could be the
first spatial <br>
BDD or geospatial library to do that).<br>
<br>
<br>
Cheers,<br>
<br>
José<br>
<br>
<br>
All the information, source code, etc. here.<br>
[1] <br>
<a href="https://cartosig.webs.upv.es/2021/07/27/geodesic-intersection-proposed-algorithm-and-error-assessment-of-current-software/" rel="noreferrer" target="_blank">https://cartosig.webs.upv.es/2021/07/27/geodesic-intersection-proposed-algorithm-and-error-assessment-of-current-software/</a><br>
<br>
[2] <a href="https://www.mdpi.com/2076-3417/11/11/5129" rel="noreferrer" target="_blank">https://www.mdpi.com/2076-3417/11/11/5129</a><br>
<br>
Martínez-Llario JC, Baselga S, Coll E. Accurate Algorithms for
Spatial <br>
Operations on the Spheroid in a Spatial Database Management
System. <br>
Applied Sciences. 2021; 11(11):5129. <a href="https://doi.org/10.3390/app11115129" rel="noreferrer" target="_blank">https://doi.org/10.3390/app11115129</a><br>
<br>
[3] <a href="https://link.springer.com/article/10.1007/s11200-017-1020-z" rel="noreferrer" target="_blank">https://link.springer.com/article/10.1007/s11200-017-1020-z</a><br>
<br>
Baselga, S., Martínez-Llario, J.C. Intersection and
point-to-line <br>
solutions for geodesics on the ellipsoid. Stud Geophys Geod
62, 353–363 <br>
(2018). <a href="https://doi.org/10.1007/s11200-017-1020-z" rel="noreferrer" target="_blank">https://doi.org/10.1007/s11200-017-1020-z</a><br>
<br>
[4] <a href="https://github.com/jomarlla/geodesicSpatialOperators" rel="noreferrer" target="_blank">https://github.com/jomarlla/geodesicSpatialOperators</a><br>
<br>
<br>
-- <br>
-------------------------------<br>
José Carlos Martínez Llario<br>
<a href="http://www.upv.es/ficha-personal/jomarlla" rel="noreferrer" target="_blank">http://www.upv.es/ficha-personal/jomarlla</a><br>
<a href="https://cartosig.webs.upv.es" rel="noreferrer" target="_blank">https://cartosig.webs.upv.es</a><br>
Producción Cartográfica y SIG.<br>
Dpto. Ingeniería Cartográfica.<br>
Univ. Politécnica de Valencia.<br>
-------------------------------<br>
<br>
_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-users</a><br>
</blockquote>
</div>
<br>
<fieldset></fieldset>
<pre>_______________________________________________
postgis-users mailing list
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-users" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-users</a>
</pre>
</blockquote>
<pre cols="72">--
-------------------------------
José Carlos Martínez Llario
<a href="http://www.upv.es/ficha-personal/jomarlla" target="_blank">http://www.upv.es/ficha-personal/jomarlla</a>
<a href="https://cartosig.webs.upv.es" target="_blank">https://cartosig.webs.upv.es</a>
Producción Cartográfica y SIG.
Dpto. Ingeniería Cartográfica.
Univ. Politécnica de Valencia.
-------------------------------</pre>
</div>
_______________________________________________<br>
postgis-users mailing list<br>
<a href="mailto:postgis-users@lists.osgeo.org" target="_blank">postgis-users@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/postgis-users" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/postgis-users</a><br>
</blockquote></div>