[postgis-users] Corrupted topology when using totopogeom in 3D topology
26 views
Skip to first unread message
Alexandre Silva
Aug 26, 2022, 7:14:22 AM8/26/22
to postgi...@lists.osgeo.org
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://imgur.com/a/FgIVyMO - here is the visual of the data for the error and non-error approach
https://pastebin.com/CR5dNYSZ - 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://www.postgis.net/docs/doxygen/3.0/d6/d03/lwgeom__topo_8c_source.html),
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
Regina Obe
Aug 29, 2022, 5:29:22 PM8/29/22
to PostGIS Users Discussion
I think the issue is that postgis topology only works with 2D and simply just carries the Z. So all its assumptions about closedness and intersection are based on the 2D plane.
Thanks,
Regina
Sandro Santilli
Sep 3, 2022, 3:45:25 AM9/3/22
to PostGIS Users Discussion
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;
_______________________________________________
postgis-users mailing list
postgi...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/postgis-users
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;
postgis-users mailing list
postgi...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/postgis-users
Alexandre Silva
Sep 6, 2022, 5:50:15 AM9/6/22
to PostGIS Users Discussion
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-us...@lists.osgeo.org> em nome de Sandro Santilli <st...@kbt.io>
Enviado: 3 de setembro de 2022 08:45
Para: PostGIS Users Discussion <postgi...@lists.osgeo.org>
Assunto: Re: [postgis-users] Corrupted topology when using totopogeom in 3D topology
Enviado: 3 de setembro de 2022 08:45
Para: PostGIS Users Discussion <postgi...@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).
>
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.
> 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
postgi...@lists.osgeo.org
Alexandre Silva
Sep 6, 2022, 6:03:48 AM9/6/22
to PostGIS Users Discussion
Yes, it appears the bug is that that assumption is not being fulfilled. A bug ticket is already submitted.
Thanks for your response,
Alexandre
De: postgis-users <postgis-us...@lists.osgeo.org> em nome de Regina Obe <l...@pcorp.us>
Enviado: 29 de agosto de 2022 22:29
Enviado: 29 de agosto de 2022 22:29
Assunto: Re: [postgis-users] Corrupted topology when using totopogeom in 3D topology
Sandro Santilli
Nov 3, 2022, 4:13:51 PM11/3/22
to PostGIS Users Discussion
On Tue, Sep 06, 2022 at 09:50:04AM +0000, Alexandre Silva wrote:
> 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
Thank you for your report.
> 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
The regression should now be fixed in all branches
(was introduced in 3.0.2).
--strk;
_______________________________________________
postgis-users mailing list
postgi...@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/postgis-users
postgis-users mailing list
postgi...@lists.osgeo.org
Alexandre Silva
Dec 21, 2022, 6:16:59 AM12/21/22
to PostGIS Users Discussion
Sorry for not replying sooner but only now I could test it.
Can confirm that the topology that was having errors (with around
10k linestrings) now finishes without any errors.
Thanks for your help.
Enviado: 3 de novembro de 2022 20:13
Para: PostGIS Users Discussion <postgi...@lists.osgeo.org>
Assunto: Re: [postgis-users] Corrupted topology when using totopogeom in 3D topology
On Tue, Sep 06, 2022 at 09:50:04AM +0000, Alexandre Silva wrote:
> Hey Sandro,
>
> Thanks for your help.
> Hey Sandro,
>
> Thanks for your help.
> Here's the ticket in case anyone wants to follow this bug:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftrac.osgeo.org%2Fpostgis%2Fticket%2F5234&data=05%7C01%7Camsilva%40infoportugal.impresa.pt%7C286c39bd530848c21ecc08dabdd7ef4c%7Cd227b2e71c404f63b5132f3665c334e6%7C0%7C0%7C638031032388985375%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sw9O2I6gZefA77pe55kvH5k8k7TGfeN1TcPwa2C4Uuc%3D&reserved=0
Thank you for your report.
The regression should now be fixed in all branches
(was introduced in 3.0.2).
--strk;
_______________________________________________
postgis-users mailing list
postgi...@lists.osgeo.org
Reply all
Reply to author
Forward
0 new messages