Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Use GEOSNode instead of UnaryUnion for ST_Node; fixes #3647 #136
oh I forgot we also agreed on sprint to bump to 3.5
But I asked on mailing list just in case anyone has a serious objection:
On Tue, Aug 22, 2017 at 12:37 PM, Regina Obe ***@***.***> wrote: @pramsey <https://github.com/pramsey> are you around? I wanted to accept this pull request, but I'd have to change the configure.ac to do so to make 3.5 the minimum and I think you are still working on it. If you haven't started yet, I can do that, but didn't want to disrupt your surgery. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#136 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAG828rE0mSXdw4voHbkPTPOn4_EGuKNks5say34gaJpZM4O2MtZ> .
please be careful about semantics, this is a fundamental function used by topology and I believe it is expected to retain the nodes originally in the input. Noding should only add nodes, not remove them. You can see the code keeps track of unique nodes in input before running LineMerge for exactly that purpose.
It seems that GEOSNode does not perform LineMerge:
My changes have been reverted, and now the only change is that GEOSNode is applied in stead of GEOSUnaryUnion. The preservation of nodes has been restored. In this case the tests need not be changed, except for the one cu_node.c case where only the lines change order and direction.
I was thinking of adding a note to the docs mentioning the changed behavior in the next major Postgis version. The docs indeed already mention that all input nodes are preserved.