[postgis-tickets] [PostGIS] #4747: Re: [PostGIS] #4745: Possible problem with new version 2.5.5

[PostGIS]

#4747: Re: [PostGIS] #4745: Possible problem with new version 2.5.5
------------------------+---------------------------
  Reporter:  ezimanyi   |      Owner:  pramsey
      Type:  defect     |     Status:  closed
  Priority:  medium     |  Milestone:  PostGIS 3.1.0
 Component:  postgis    |    Version:  2.5.x
Resolution:  duplicate  |   Keywords:
------------------------+---------------------------

Comment (by ezimanyi):

 Dear Raúl

 Many many thanks for helping me to solve the compatibility problem with
 PostGIS 2.5.5. I was able to succeed the regression tests again
 https://github.com/MobilityDB/MobilityDB/commits/develop
 Indeed, as you suggested, I needed to cache the outermost fcinfo in a
 global variable.

 Concerning your suggestion to depend on PostGIS SQL API, this was the case
 of our initial MobilityDB implementation but it was impossible to use
 because it was too slow. A typical use case for MobilityDB is to analyze
 maritime data as explained in the MobilityDB workshop.
 https://github.com/MobilityDB/MobilityDB-workshop
 Example of such open data is provided by the Danish Maritime authority
 ftp://ftp.ais.dk/ais_data/

 Each of these CSV files for a single day contains around 300 ship trips
 for a total of more than 10M points which means that each trip has between
 3K and 4K timestamped points. We need to analyze the potential collision
 risks as shown next
 * [https://docs.mobilitydb.com/MobilityDB-
 workshop/master/ch01s08.html#imgApproach1]
 * [https://docs.mobilitydb.com/MobilityDB-
 workshop/master/ch01s08.html#imgApproach2]

 We cannot afford to use the SQL API for performance reasons. Indeed, to
 create a single trip with 4K points we need to
 * call 4K times the function ST_MakePoint
 * call 4K times the function ST_SetSRID to specify that the input data is
 in 4326 SRID
 * call 4K times the function ST_Transform to put the data in the 25832
 SRID.
 And all this only to load the data of a single day before analyzing every
 couple of trips in the data set, synchronizing the two trips to obtain 2
 trips of 4K + 4K synchronized points and
 * call  4K + 4K times the function ST_Distance for each couple of trips.
 As you can imagine, for such kind of manipulations we really need to
 access directly the liblwgeom library. The situation is much more
 challenging for aviation data obtained from, e.g.,
 https://developer.laminardata.aero/

 For these reasons we really need to collaborate with you in order to
 connect as efficiently as possible MobilityDB and PostGIS. Indeed, the
 overall philosophy of MobilityDB is take care of the temporal aspects and
 completely delegate the spatial manipulation to PostGIS. Our role is then
 to understand at which timestamps the current value of a spatial function
 may change and call PostGIS to compute the function at those timestamps.

-- 
Ticket URL: <https://trac.osgeo.org/postgis/ticket/4747#comment:6>
PostGIS <http://trac.osgeo.org/postgis/>
The PostGIS Trac is used for bug, enhancement & task tracking, a user and developer wiki, and a view into the subversion code repository of PostGIS project.