[postgis-devel] different result ST_Tesselate from invalid polygon that ST_IsValid says is valid

Wed Apr 25 04:26:58 PDT 2018

Hi Nicklas,

I have the same issue on "POSTGIS=""2.5.0dev r16509"" [EXTENSION]
PGSQL=""100"" GEOS=""3.6.2-CAPI-1.10.2 4d2925d6"" SFCGAL=""1.3.1""
PROJ=""Rel. 4.9.3, 15 August 2016"" GDAL=""GDAL 2.2.3, released
2017/11/20"" LIBXML=""2.9.4"" LIBJSON=""0.12.1"" LIBPROTOBUF=""1.2.1""
RASTER (sfcgal procs from ""2.5.0dev r16327"" need upgrade)"

Likely the error comes from the validity check in sfcgal:

https://github.com/Oslandia/SFCGAL/blob/561c301a24a76425716ec321d1c5b2229b9e1bd2/src/algorithm/isValid.cpp#L284

I know that during the build-time of sfcgal you can disable the
validity-check (which can dramatically increase your processing time) so
maybe you have one version where this option has been disabled at build?

Best,
 Tom

On Tue, Apr 24, 2018 at 10:24 PM, Nicklas Avén <nicklas.aven at jordogskog.no>
wrote:

> Thanks Martin!
>
> I realize you of course are right when looking closer on it. It was all
> those intersections between the holes and boundary that made me think so.
> But it is actually 3 holes :-)
>
> Then I guess that the error message comes from libcgal and probably boost
> when running st_tesselate.
>
> So then my confusion moves to why ST_Tesselate works on 1 computor but not
> on another with same OS, same versions of PostGIS code.
>
> I also don't fully understand the error message:
> ERROR:  Polygon is invalid : interior is not connected
>
> Since it is all integer values I don't understand that there should be any
> machine dependent differences when judging validity.
>
> This is about the packaging of TilelessMap. I have to find a better way of
> doing the triangulation since, in the end I don't want the triangle
> coordinates but just their index in the boundary.
>
> It is the ugly scripts here that I need to find a way to handle invalid
> geometries and ugly geometries like this.
> https://github.com/TilelessMap/pg_tileless
> Thanks
>
> Nicklas
>
>
>
> On Tue, 2018-04-24 at 12:39 -0700, Martin Davis wrote:
>
> It's ugly, but it is valid according to SFS rules (which is what
> JTS/GEOS/PostGIS implement).
>
> Why do you think it is not valid?
>
> On Tue, Apr 24, 2018 at 11:48 AM, Nicklas Avén <nicklas.aven at jordogskog.no
> > wrote:
>
> Hello
>
> I have an ugly polygon, presented as wkt here below.
>
> It is really ugly, and from what I understand it has selfintersection
> and other things taht I expected ST_Isvalid to react on.
>
> But ST_Isvalid let's it through.
>
> And on 2 of my PostGIS installations ST_Tesselate gives a reasonable
> answer. But on a third installation on a virtual machine at Linode I
> get an error message which I am not sure where it comes from. It says:
> ERROR:  Polygon is invalid : interior is not connected
>
> Does that come from boost?
>
> So this is 2 questions:
>
> 1) Why doesn't ST_Isvalid tell me it is invalid
> 2) Where should I search for the different results?
>
> As far as I can find I have the exactly same versions on everything on
> the installs.
>
>
>  POSTGIS="2.5.0dev r16554" [EXTENSION] PGSQL="100" GEOS="3.7.0dev-CAPI-
> 1.11.0 r" SFCGAL="1.3.0" PROJ="Rel. 4.9.3, 15 August 2016" GDAL="GDAL
> 2.1.2, released 2016/10/24" LIBXML="2.9.4" LIBJSON="0.12.1" RASTER
> (1 row)
>
> and boost version seems to be the same
> Package: libboost-system1.62.0
>
> Could someone else with sfcgal enabled see what result they get?
>
> select st_tesselate(
> 'POLYGON((389923 6365025,390094 6364730,390269 6364430,390261
> 6364415,390250 6364399,390239 6364372,390207 6364367,390168
> 6364372,390136 6364377,390100 6364393,390081 6364429,390070
> 6364458,390059 6364474,390059 6364494,390044 6364497,390019
> 6364506,390012 6364512,389985 6364533,389973 6364545,389951
> 6364567,389931 6364588,389927 6364598,389912 6364628,389907
> 6364636,389883 6364647,389870 6364649,389863 6364638,389858
> 6364613,389851 6364591,389817 6364575,389795 6364594,389792
> 6364625,389791 6364653,389796 6364679,389802 6364695,389811
> 6364722,389840 6364741,389868 6364741,389882 6364721,389900
> 6364705,389915 6364699,389915 6364717,389909 6364737,389891
> 6364770,389885 6364781,389867 6364798,389845 6364810,389823
> 6364809,389801 6364815,389778 6364822,389761 6364822,389742
> 6364840,389732 6364863,389741 6364890,389741 6364919,389744
> 6364920,389760 6364932,389768 6364940,389774 6364954,389776
> 6364963,389787 6364970,389816 6364981,389852 6364993,389895
> 6365011,389923 6365025),(390094 6364730,389987 6364914,389981
> 6364904,389971 6364887,389947 6364869,389921 6364853,389895
> 6364832,389892 6364816,389906 6364812,389941 6364818,389973
> 6364827,390021 6364852,390094 6364730),(390094 6364730,390050
> 6364714,390050 6364713,390094 6364730),(390050 6364714,390034
> 6364736,390014 6364733,389982 6364724,389954 6364721,389953
> 6364710,389958 6364695,389964 6364677,389972 6364672,389988
> 6364673,390015 6364678,390041 6364695,390049 6364713,390047
> 6364713,390050 6364714))'::geometry);
>
>
> Thanks
>
> Nicklas
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
>
> _______________________________________________
> postgis-devel mailing listpostgis-devel at lists.osgeo.orghttps://lists.osgeo.org/mailman/listinfo/postgis-devel
>
>
> _______________________________________________
> postgis-devel mailing list
> postgis-devel at lists.osgeo.org
> https://lists.osgeo.org/mailman/listinfo/postgis-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-devel/attachments/20180425/7587aa99/attachment-0001.html>