[postgis-users] Corrupted topology when using totopogeom in 3D topology

Alexandre Silva amsilva at infoportugal.impresa.pt
Tue Sep 6 02:50:04 PDT 2022


Hey Sandro,

Thanks for your help.
Here's the ticket in case anyone wants to follow this bug: https://trac.osgeo.org/postgis/ticket/5234

Regards,
Alexandre






________________________________
De: postgis-users <postgis-users-bounces at lists.osgeo.org> em nome de Sandro Santilli <strk at kbt.io>
Enviado: 3 de setembro de 2022 08:45
Para: PostGIS Users Discussion <postgis-users at lists.osgeo.org>
Assunto: Re: [postgis-users] Corrupted topology when using totopogeom in 3D topology

Hi Alexandre, I can reproduce the problem you reported with version
3.3.0, could you please file a ticket on trac.osgeo.org/postgis with
all the detail ?  It sounds like a regression.
Use component "Topology" please.

I confirm using 2D only works fine.

Gory details: the problem likely lays in _lwt_MakeRingShell which
was recently changed to NOT use GEOS but rather do things internally,
to reduce overhead. The internal implementation is NOT dropping the Z
as the geos implementation did.

Your filing a ticket will greatly help :)

--strk;

On Fri, Aug 26, 2022 at 11:14:11AM +0000, Alexandre Silva wrote:
> Hello,
>
> I'm having some trouble creating a 3D topology using totopogeom method, I don't know if I'm not using the functions correctly or if there's indeed a bug, so any help would be appreciated.
>
> I reduced the problem to an example with two lines.
> The first line is added with no errors to the topology but the second one throws this error "Corrupted topology: ring of edge -3 is geometrically not-closed".
> The second line intersects with the first one, but there's no vertex on the intersection.
> I found two workarounds but both of them have some disadvantages in my point of view.
> The first one was to add manually a vertex on the intersection (this involves someone doing that work manually).
> The other one was to add the start and end point of every line using topogeo_addpoint before calling totopogeom (this involves remembering to do this every time that I create a topology and I think it's redundant and overhead for most cases).
>
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fimgur.com%2Fa%2FFgIVyMO&data=05%7C01%7Camsilva%40infoportugal.impresa.pt%7C57f9741523ab4ee1d13808da8d8046ab%7Cd227b2e71c404f63b5132f3665c334e6%7C0%7C0%7C637977879337565417%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=jERGJpOTNiHjFpaQaZYdkfINjj4JzUdspHRq77FDDAE%3D&reserved=0 - here is the visual of the data for the error and non-error approach
> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpastebin.com%2FCR5dNYSZ&data=05%7C01%7Camsilva%40infoportugal.impresa.pt%7C57f9741523ab4ee1d13808da8d8046ab%7Cd227b2e71c404f63b5132f3665c334e6%7C0%7C0%7C637977879337565417%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZjoU8Z38xyEmaOm8anqKtVAW076ZcKasNEaF%2F03dRig%3D&reserved=0 - here is a script to emulate the error, with the two workarounds commented
>
> Not having much knowledge of the c code base, just looking at the code surrounding the error (https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.postgis.net%2Fdocs%2Fdoxygen%2F3.0%2Fd6%2Fd03%2Flwgeom__topo_8c_source.html&data=05%7C01%7Camsilva%40infoportugal.impresa.pt%7C57f9741523ab4ee1d13808da8d8046ab%7Cd227b2e71c404f63b5132f3665c334e6%7C0%7C0%7C637977879337565417%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=mB3%2FpACSaikBNVA%2BNy7Wz9nSY%2B3OtEo3qi%2FdON5mNm8%3D&reserved=0), my wild guess is that when it creates the ring of the newly closed area, and as there is no vertex on the intersection so no snap made, the ring is closed on 2D dimension but there is a 3D gap that makes the ring not geometrically closed. My reasoning for this is that the same data with a 2D topology has no errors and if I reverse the insertion order (there would be a node on the intersection), it also works. I can also be completely wrong.
>
> This error was tested on docker image postgis/postgis:14-3.2-alpine with postgis version:
> POSTGIS="3.2.1 0" [EXTENSION] PGSQL="140" GEOS="3.10.2-CAPI-1.16.0" PROJ="8.2.0" LIBXML="2.9.13" LIBJSON="0.15" LIBPROTOBUF="1.4.0" WAGYU="0.5.0 (Internal)" TOPOLOGY
>
> There's no error in this version (also running in docker):
> POSTGIS="3.0.1 ec2a9aa" [EXTENSION] PGSQL="120" GEOS="3.7.1-CAPI-1.11.1 27a5e771" SFCGAL="1.3.6" PROJ="Rel. 5.2.0, September 15th, 2018" GDAL="GDAL 2.4.0, released 2018/12/14" LIBXML="2.9.4" LIBJSON="0.12.1" LIBPROTOBUF="1.3.1" WAGYU="0.4.3 (Internal)" TOPOLOGY RASTER
>
> Thanks,
> Alexandre Silva
_______________________________________________
postgis-users mailing list
postgis-users at lists.osgeo.org
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fpostgis-users&data=05%7C01%7Camsilva%40infoportugal.impresa.pt%7C57f9741523ab4ee1d13808da8d8046ab%7Cd227b2e71c404f63b5132f3665c334e6%7C0%7C0%7C637977879337565417%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=l135Asxk4K2vLjDZwO2Jb4MPxn9QumaSORdubgY4%2FTo%3D&reserved=0
[http://newsletter.impresapublishing.pt/i/barra_ip.jpg]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/postgis-users/attachments/20220906/9f0abe17/attachment.htm>


More information about the postgis-users mailing list