[postgis-devel] PostGIS 3 and MobilityDB

[Esteban Zimanyi]

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> 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/20210708/16a6884b/attachment.html>