<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>A side note, I think you need to change the way you are detecting PostgreSQL. It just doesn’t work for me and suspect it will be an issue for anyone with multiple PostgreSQL installs or non-standard paths – as I had mentioned here - <a href="https://github.com/MobilityDB/MobilityDB/pull/20">https://github.com/MobilityDB/MobilityDB/pull/20</a> . You should be using the <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>CMAKE PostgreSQL package to detect PostgreSQL. I always end up having to copy pgRouting code in so the PostgreSQL detection works right.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>As I recall compiling MobilityDB a while ago it has both a dependency to liblwgeom as well as the PostGIS lib.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>The dependency of PostGIS lib is a little troubling as I mentioned here<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><a href="https://github.com/MobilityDB/MobilityDB/issues/16">https://github.com/MobilityDB/MobilityDB/issues/16</a><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> Even the extensions packaged with PostGIS don’t have a direct dependency to PostGIS lib just to liblwgeom.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>So not even a parallel branch will work here unless you change how you are doing things and what to change is unclear to me. The issue with depending on PostGIS lib is we only guarantee SQL API compatibility across minor versions, not C-API. Meaning if the function isn’t exposed via the SQL API, we don’t need to worry about it as PostgreSQL upgrade would not care as it only fails if it tries to call a function that is referenced in an SQL API function.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>That said if you must rely on PostGIS lib all your postgis.h dependencies should only be Datum ones and any others will make your code brittle to PostGIS changes.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>I’m thinking for the liblwgeom dependency you should be able to use librtopo for that. Still not clear to me why you can’t, but we can discuss in dev meeting.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>My understanding of the main speed issue is the serializing and deserializing of data across the PostgreSQL barrier.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>One thought that comes to mind which I’ve been thinking about (perhaps crazy), is some sort of iterator function where you pass a bytea or jsonb representation of data (has to be bytea or jsonb or some other so we have no direct dependency to mobility types or any other non-built-in types) and you define the instruction. Similar to the jsonb_path <o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><a href="https://www.youtube.com/watch?v=LOXmgM8Vtqc">https://www.youtube.com/watch?v=LOXmgM8Vtqc</a><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>except it would be some sort of operation of the form<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>SELECT postgis_iterate(your_data, ‘interation query’);<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Where the query would define possible agreed upon function names and what to do with the data and outputs back a bytea of the operation.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>If it’s bytea I suppose we could have code internal to PostGIS that can understand tpoint and other types mobility uses.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Not sure if that would help solve similar issue Darafei mentioned with h3-pg - https://github.com/bytesandbrains/h3-pg<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Thanks,<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Regina<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'><o:p> </o:p></span></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'>From:</span></b><span style='font-size:11.0pt;font-family:"Calibri",sans-serif'> postgis-devel [mailto:postgis-devel-bounces@lists.osgeo.org] <b>On Behalf Of </b>Esteban Zimanyi<br><b>Sent:</b> Thursday, July 8, 2021 9:00 AM<br><b>To:</b> PostGIS Development Discussion <postgis-devel@lists.osgeo.org><br><b>Cc:</b> Mahmoud Sakr <m_attia_sakr@yahoo.com>; mohamed sayed <mohamed_bakli@aun.edu.eg>; SCHOEMANS Maxime <Maxime.Schoemans@ulb.be><br><b>Subject:</b> Re: [postgis-devel] PostGIS 3 and MobilityDB<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>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<o:p></o:p></p><div><p class=MsoNormal><o:p> </o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Wed, Jul 7, 2021 at 10:46 AM Regina Obe <<a href="mailto:lr@pcorp.us">lr@pcorp.us</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>How many functions are we talking about here in this postgis_c_api and how many of these are not already covered in librttopo?</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>> </span>Statically linking to the copy of liblwgeom will cause explosions when using two versions with same func names at the same time.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>I haven’t seen the issue you described here for a couple of years now.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>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><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>Signup is here - <a href="https://nextcloud.osgeo.org/apps/polls/s/4w1vSTPsIuJySw7g" target="_blank">https://nextcloud.osgeo.org/apps/polls/s/4w1vSTPsIuJySw7g</a><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Thanks,</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'>Regina</span><o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><span style='font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D'> </span><o:p></o:p></p></div></div></blockquote></div></div></div></div></body></html>