<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr"><div dir="ltr">Dear Regina<br><br>Many thanks for allowing us to participate in the PostGIS Day Development meeting 2021.<br><br>Allow me to explain further why a solution based on lbrttopo is not viable for us. A foundational result of moving object databases is the fact that ANY function on static geometries (i.e., those manipulated by PostGIS) can be generalized to temporal (or moving) geometries (i.e., those manipulated by MobilityDB). This is called LIFTING and conceptually this amounts to applying the static function to every timestamp of the moving geometry. For obvious performance reasons lifting cannot be implemented like this. The approach followed by MobilityDB is to fully delegate the static function to PostGIS and to determine the minimal number of timestamps at which the PostGIS function needs to be called. This is explained in the article<br><a href="https://docs.mobilitydb.com/pub/TODS.pdf">https://docs.mobilitydb.com/pub/TODS.pdf</a><br><br>The mainstream MobilityDB version implements the OGC Moving Features Access standard <br><a href="https://docs.opengeospatial.org/is/16-120r3/16-120r3.html">https://docs.opengeospatial.org/is/16-120r3/16-120r3.html</a><br>for moving POINTS (i.e., something like 'Point(1 1)@t1, Point(2 2)@t2, ....'). As stated above in this thread, for implementing this we required<br>* the functions in liblwgeom.h<br>* the functions stated in the postgis.h file<br><a href="https://github.com/MobilityDB/MobilityDB/blob/develop/point/include/postgis.h">https://github.com/MobilityDB/MobilityDB/blob/develop/point/include/postgis.h</a><br><br>However, the ISO standard ISO 19141:2008 Geographic information — Schema for moving features<br><a href="https://www.iso.org/standard/41445.html">https://www.iso.org/standard/41445.html</a><br>requires to implement moving GEOMETRIES, more precisely RIGID (i.e. non-deforming) temporal geometries. Our initial implementation of this standard is explained in the article <br><a href="https://docs.mobilitydb.com/pub/TempGeometriesICDE2021.pdf">https://docs.mobilitydb.com/pub/TempGeometriesICDE2021.pdf</a><br>We are currently implementing OGC Moving Features Access standard for rigid temporal geometries and it is impossible to know upfront what are the PostGIS functions we would need for that.<br><br>As mentioned above in this thread, we are willing to do ANYTHING in our code to enable a sustainable way to access PostGIS functions in MobilityDB. This could include, e.g., Paul's suggestion to refactor our code as a parallel branch to postgis_raster and the other PostGIS extensions.<br><br>Regards<br><br>Esteban<br><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jul 7, 2021 at 10:46 AM Regina Obe <<a href="mailto:lr@pcorp.us">lr@pcorp.us</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"><div lang="EN-US"><div class="gmail-m_1681813533592008249WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">How many functions are we talking about here in this postgis_c_api and how many of these are not already covered in librttopo?<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">> </span>Statically linking to the copy of liblwgeom will cause explosions when using two versions with same func names at the same time.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">I thought we had that solved so each static can’t see the other functions inside (I forget what we changed – I think Sandro had changed it something to do with not exporting symbols I think it was).  We had issues with this with raster, sfcgal, and postgis_topology earlier on cause they each have their own static copy of liblwgeom which each exported the symbols and were dancing around in an unwholesome manner.<u></u><u></u></p><p class="MsoNormal">I haven’t seen the issue you described here for a couple of years now.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">My main concern with a postgis_c_api is that sounds like MobilityDB needs a lot of the functions which would mean that library would get fat very quickly and bind their versioning to our versioning.  I’d rather sort out why librtopo <a href="https://git.osgeo.org/gitea/rttopo/librttopo" target="_blank">https://git.osgeo.org/gitea/rttopo/librttopo</a> is not a viable solution while liblwgeom is as the point of librttopo was to have a minimalist liblwgeom<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">MobilityDB folks – you are welcome to our Dev meeting -  <a href="https://trac.osgeo.org/postgis/wiki/PostGISDevelopment2021" target="_blank">https://trac.osgeo.org/postgis/wiki/PostGISDevelopment2021</a><u></u><u></u></p><p class="MsoNormal">Signup is here -  <a href="https://nextcloud.osgeo.org/apps/polls/s/4w1vSTPsIuJySw7g" target="_blank">https://nextcloud.osgeo.org/apps/polls/s/4w1vSTPsIuJySw7g</a><u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Thanks,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)">Regina<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11pt;font-family:Calibri,sans-serif;color:rgb(31,73,125)"><u></u> </span></p></div></div>
</blockquote></div></div>