<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr">I was able to produce a first build that works for both PostGIS 2.5.5 and 3.1.3. This is great news since we have been waiting for almost two years to be able to make MobilityDB work with PostGIS 3 !<div><br></div><div>The build is in the branch<div><a href="https://github.com/MobilityDB/MobilityDB/tree/towards-postgis3">https://github.com/MobilityDB/MobilityDB/tree/towards-postgis3</a><br></div><div>There is still one test (51_tpoint.test.sql) that gives different results in version 3.1.3. The reason may be that the lwgeom_hash function was changed in version 3.1.3. I will look at this in the forthcoming days.</div><div><br></div><div>The source files of the PostGIS directories liblwgeom, libpgcommon, and ryu were copied into the directory MobilityDB/postgis, in addition to the two files postgis_config.h and postgis_revision.h. Minimal changes were done to these files, basically removing static keywords for the functions getSRSbySRID, getSRIDbySRS and circ_tree_distance_tree_internal so that they can be called by MobilityDB.</div><div><br></div><div>The basic idea of the build is that if a PostGIS version less than 3.0 is found, then library liblwgeom.so is loaded. Otherwise, the directory MobilityDB/postgis is added to the build.</div><div><br></div><div>Please notice that this is still a proof-of-concept build. Indeed, I first built PostGIS 3.1.3 in my machine and therefore this build generated the right parameters for the files postgis_config.h and postgis_revision.h that are embedded in MobilityDB/postgis. This concerns in particular the setting of the machine endian constant. Therefore, we need to replicate in MobilityDB some of the configuration PostGIS makes in order to produce the right postgis_config.h and postgis_revision.h according to the machine characteristics at hand. I will work on that in the forthcoming days.</div><div><br></div><div>Esteban</div><div><br></div></div></div>