[postgis-devel] PostGIS 3 and MobilityDB

Thu Jul 8 23:26:54 PDT 2021

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 - https://github.com/MobilityDB/MobilityDB/pull/20 .  You should be using the 

CMAKE PostgreSQL package to detect PostgreSQL.  I always end up having to copy pgRouting code in so the PostgreSQL detection works right.

As I recall compiling MobilityDB a while ago it has both a dependency to liblwgeom as well as the PostGIS lib.

The dependency of PostGIS lib is a little troubling as I mentioned here

https://github.com/MobilityDB/MobilityDB/issues/16

Even the extensions packaged with PostGIS don’t have a direct dependency to PostGIS lib just to liblwgeom.

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.

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.

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.

My understanding of the main speed issue is the serializing and deserializing of data across the PostgreSQL barrier.

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 

https://www.youtube.com/watch?v=LOXmgM8Vtqc

except it would be some sort of operation of the form

SELECT postgis_iterate(your_data, ‘interation query’);

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.

If it’s bytea I suppose we could have code internal to PostGIS that can understand tpoint  and other types mobility uses.

Not sure if that would help solve similar issue Darafei mentioned with h3-pg -  https://github.com/bytesandbrains/h3-pg

Thanks,

Regina

From: postgis-devel [mailto:postgis-devel-bounces at lists.osgeo.org] On Behalf Of Esteban Zimanyi
Sent: Thursday, July 8, 2021 9:00 AM
To: PostGIS Development Discussion <postgis-devel at lists.osgeo.org>
Cc: Mahmoud Sakr <m_attia_sakr at yahoo.com>; mohamed sayed <mohamed_bakli at aun.edu.eg>; SCHOEMANS Maxime <Maxime.Schoemans at ulb.be>
Subject: Re: [postgis-devel] PostGIS 3 and MobilityDB

Dear Regina

Many thanks for allowing us to participate in the PostGIS Day Development meeting 2021.

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
https://docs.mobilitydb.com/pub/TODS.pdf

The mainstream MobilityDB version implements the OGC Moving Features Access standard 
https://docs.opengeospatial.org/is/16-120r3/16-120r3.html
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
* the functions in liblwgeom.h
* the functions stated in the postgis.h file
https://github.com/MobilityDB/MobilityDB/blob/develop/point/include/postgis.h

However, the ISO standard ISO 19141:2008 Geographic information — Schema for moving features
https://www.iso.org/standard/41445.html
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 
https://docs.mobilitydb.com/pub/TempGeometriesICDE2021.pdf
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.

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.

Regards

Esteban

On Wed, Jul 7, 2021 at 10:46 AM Regina Obe <lr at pcorp.us <mailto:lr at pcorp.us> > wrote:

How many functions are we talking about here in this postgis_c_api and how many of these are not already covered in librttopo?

> Statically linking to the copy of liblwgeom will cause explosions when using two versions with same func names at the same time.

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.

I haven’t seen the issue you described here for a couple of years now.

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 https://git.osgeo.org/gitea/rttopo/librttopo is not a viable solution while liblwgeom is as the point of librttopo was to have a minimalist liblwgeom

MobilityDB folks – you are welcome to our Dev meeting -  https://trac.osgeo.org/postgis/wiki/PostGISDevelopment2021

Signup is here -  https://nextcloud.osgeo.org/apps/polls/s/4w1vSTPsIuJySw7g

Thanks,

Regina

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20210709/180a3a00/attachment.html>