<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr"><div dir="ltr">Dear Paul<br><br>Since you mention geodetic functions, we implemented a year ago some geography functions to be submitted as PR to PostGIS but we haven't had time to do it. These functions are geography_closestpoint, geography_shortestline, geography_line_substring, geography_line_interpolate_point, and geography_line_locate_point. You can find these functions at the following address<br><a href="https://github.com/MobilityDB/MobilityDB/blob/develop/point/src/geography_functions.c">https://github.com/MobilityDB/MobilityDB/blob/develop/point/src/geography_functions.c</a><br><br></div><div>It may be useful to have such functionality in PostGIS.</div><div><br></div><div dir="ltr">Regards<br><br>Esteban<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jul 9, 2021 at 5:54 PM Paul Ramsey <<a href="mailto:pramsey@cleverelephant.ca">pramsey@cleverelephant.ca</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">I really wonder whether just copying over the liblwgeom functions they really really need into their own code base isn't the most straight-forward thing. Once that's done the only real point-of-integration is the serialization, and that only changes once every 10 years, so... keeping an eye on the postgis serialization code to watch for changes once a year is a relatively small price to pay. <br>
<br>
Everything else is just "useful functionality that happens to be in postgis", and can probably just be copied across and given a new function name prefix to avoid collisions. At that point they are stuck maintaining their copy, but it's not like postgis is some massively churning code base at this point. Core lwgeom stuff changes infrequently at most. You might see some re-writes in geodetic from me, but that wouldn't invalidate the current code if they had a working copy.<br>
</blockquote></div></div>