[Mobilitydb-dev] Update about my experiments integrating PostGIS 3.1.3 and MobilityDB
Anita Graser
anitagraser at gmx.at
Tue Aug 24 11:12:33 PDT 2021
Great to have you, Regina!
Regards,
Anita
On 24.08.2021 06:18, Regina Obe wrote:
>
> Just an FYI I am now subscribed to the mobilitydb dev mailing list, so
> all this kind of correspondence should continue there.
>
> It will allow for others who are interested to get more involved.
>
> Thanks,
>
> Regina
>
> *From:*Esteban Zimanyi [mailto:estebanzimanyi at gmail.com]
> *Sent:* Monday, August 23, 2021 12:59 PM
> *To:* Vicky Vergara <vicky at georepublic.de>
> *Cc:* mobilitydb-dev at lists.osgeo.org; Regina Obe <lr at pcorp.us>;
> 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: Update about my experiments integrating PostGIS 3.1.3
> and MobilityDB
>
> I always solved that problem with the setPrecision functions
>
> https://docs.mobilitydb.com/MobilityDB/develop/ch04s05.html#box_setPrecision
> <https://docs.mobilitydb.com/MobilityDB/develop/ch04s05.html#box_setPrecision>
>
> https://docs.mobilitydb.com/MobilityDB/develop/ch05s06.html#tpoint_setPrecision
> <https://docs.mobilitydb.com/MobilityDB/develop/ch05s06.html#tpoint_setPrecision>
>
> You can find numerous setPrecision calls in all the tests. I needed to
> do that when switching to PosgreSQL 13 because the output of the
> floating point values were different between versions.
>
> The difference now is that in PostGIS 3 they started using the ryu
> library for output coordinates. The difference wrt the other tests is
> that we need to output a geometry/geography as result of the
> trajectory function.
>
> I have almost finished today to write a simple setPrecision function
> for geometry/geography so that for example, the test
>
> SELECT ST_AsText(trajectory(tnpoint 'Npoint(1, 0.5)@2000-01-01'));
>
> will be replaced by
>
> SELECT ST_AsText(setPrecision(trajectory(tnpoint 'Npoint(1,
> 0.5)@2000-01-01'), 6));
>
> and this will solve the multiplatform variation for the tests.
>
>
> ------------------------------------------------------------
> Prof. Esteban Zimanyi
> Department of Computer & Decision Engineering (CoDE) CP 165/15
> Universite Libre de Bruxelles
> Avenue F. D. Roosevelt 50
> B-1050 Brussels, Belgium
> fax: + 32.2.650.47.13
> tel: + 32.2.650.31.85
> e-mail: esteban.zimanyi at ulb.be <mailto:esteban.zimanyi at ulb.be>
> Internet: http://cs.ulb.ac.be/members/esteban/
> <http://cs.ulb.ac.be/members/esteban/>
> ------------------------------------------------------------
>
> On Mon, Aug 23, 2021 at 6:42 PM Vicky Vergara <vicky at georepublic.de
> <mailto:vicky at georepublic.de>> wrote:
>
> Yeah, I have that problem also when testing on different
> platforms/compilers/postgres
> But I resolved by using on some tests that were having precision
> problems with:
> SET extra_float_digits = *-3*;
> https://github.com/pgRouting/pgrouting/blob/main/pgtap/withPoints/withPoints_oneToOne-compare-dijkstra.test.sql#L30
> <https://github.com/pgRouting/pgrouting/blob/main/pgtap/withPoints/withPoints_oneToOne-compare-dijkstra.test.sql#L30>
> Documentation about that can be found here:
> https://www.postgresql.org/docs/12/datatype-numeric.html
> <https://www.postgresql.org/docs/12/datatype-numeric.html>
>
> In another case I had to resolve floating point comparison
> internally with:
> https://github.com/pgRouting/pgrouting/blob/main/src/common/xy_vertex.cpp#L36
> <https://github.com/pgRouting/pgrouting/blob/main/src/common/xy_vertex.cpp#L36>
>
> Which I got from here:
> https://en.cppreference.com/w/cpp/types/numeric_limits/epsilon
> <https://en.cppreference.com/w/cpp/types/numeric_limits/epsilon>
>
> Allways keep in mind floating point
>
> Remember for example that:
>
> mathematically: 1 == 1/3 + 1/3 + 1/3
>
> But computationally: 1 != 1/3 + 1/3 + 1/3
>
> The reason is floating point
>
> I like this article
>
> https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/
> <https://randomascii.wordpress.com/2012/02/25/comparing-floating-point-numbers-2012-edition/>
>
> On Sun, Aug 22, 2021 at 7:56 AM Esteban Zimanyi
> <estebanzimanyi at gmail.com <mailto:estebanzimanyi at gmail.com>> wrote:
>
> Dear Vicky and Regina
>
> Following the recommendations we received at the PostGIS Dev
> meeting this August 20, I started to experiment the embedding
> of liblwgeom from PostGIS 3.1.3 inside MobilityDB. I was able
> to run the MobilityDB tests but obviously things have changed
> from versions 2.5.5 to 3.1.3.
>
> You will find enclosed a diff of the results of one of the
> tests. As you can see there are two types of differences. The
> first one concerns a very small floating point precision
> difference, e.g.,
>
> SELECT ST_AsText(trajectory(tnpoint 'Npoint(1,
> 0.5)@2000-01-01'));
> - st_astext
> ---------------------------------------------
> - POINT(48.71866291282778 77.76407051015086)
> + st_astext
> +------------------------------------------
> + POINT(48.7186629128278 77.7640705101509)
> (1 row)
>
> Another type of error concerns deprecated functions
>
> SELECT setPrecision(atGeometry(tnpoint '{Npoint(1,
> 0.3)@2000-01-01, Npoint(1, 0.5)@2000-01-02, Npoint(1,
> 0.5)@2000-01-03}', geometry 'SRID=5676;Polygon((50 50,50
> 100,100 100,100 50,50 50))'), 6);
> -ERROR
> -DETAIL: Library function 'intersects' was deprecated in
> PostGIS 3.0.0
> -HINT: Consider running: SELECT postgis_extensions_upgrade()
> + setprecision
> +----------------------------------------
> + {NPoint(1,0.3)@2000-01-01 00:00:00+00}
> +(1 row)
> +
>
> In the forthcoming days I will be modifying the develop branch
> so that the tests can be run in both versions PostGIS 2.5.5
> and 3.1.3.
>
> Furthermore, as a consequence of the problem I reported on the
> ticket
>
> https://trac.osgeo.org/postgis/ticket/4979#comment:5
> <https://trac.osgeo.org/postgis/ticket/4979#comment:5>
>
> it is not possible to mix PostGIS 2.5.5 and 3.1.3 (e.g., use
> liblwgeom.so from PostGIS 2.5.5 with PostGIS 3.1.3 which was
> one of the tests planned) since all the lwgeom struct
> definitions have been changed.
>
> Regards
>
> Esteban
>
> ------------------------------------------------------------
>
> Prof. Esteban Zimanyi
> Department of Computer & Decision Engineering (CoDE) CP 165/15
> Universite Libre de Bruxelles
> Avenue F. D. Roosevelt 50
> B-1050 Brussels, Belgium
> fax: + 32.2.650.47.13
> tel: + 32.2.650.31.85
> e-mail: esteban.zimanyi at ulb.be <mailto:esteban.zimanyi at ulb.be>
> Internet: http://cs.ulb.ac.be/members/esteban/
> <http://cs.ulb.ac.be/members/esteban/>
> ------------------------------------------------------------
>
>
>
> --
>
> Georepublic UG (haftungsbeschränkt)
>
> Salzmannstraße 44,
>
> 81739 München, Germany
>
> Vicky Vergara
>
> Operations Research
>
> eMail: vicky at georepublic.de <http://georepublic.de>
>
> Web:https://georepublic.info <https://georepublic.info>
>
> Tel: +49 (089) 4161 7698-1
>
> Fax: +49 (089) 4161 7698-9
>
> Commercial register: Amtsgericht München, HRB 181428
>
> CEO: Daniel Kastl
>
>
> _______________________________________________
> Mobilitydb-dev mailing list
> Mobilitydb-dev at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/mobilitydb-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/mobilitydb-dev/attachments/20210824/ec2449b4/attachment-0001.html>
More information about the Mobilitydb-dev
mailing list