CDT with intersecting constraints

[Kruptein]

Hi, I noticed your 2.0 post and was wondering whether you have any plans or ideas to add support for intersecting constraints for the CDT.

[Stoeoef]

Would a solution that splits any intersecting edge, inserting a splitting point at their intersection, also be feasible? That would not be too difficult to implement and works well with the CDT's current structure.

[Kruptein]

Hey, I think this should be fine, don't see an immediate issue I could have with that approach, unless you can think of something I should be aware of in that case?

[Stoeoef]

Wonderful! There is one technical concern and one concern from a usability perspective: On the technical side, it "complicates" the API, since spade cannot create new vertices on its own. Spade would require a constructor fn (V::Point) -> V where V: HasPosition. This constructor can either be passed directly as an fn or be defined with a trait, e.g. V: From<V::Point>. I'm in favor of the second approach: It should work out of the box with Point types and seems to be sound from a semantical perspective.

From a usability stand point, splitting the inserted constraint edge into several parts may be unexpected. This can probably mitigated by choosing a good name in the future: add_constraint_edge and add_constraint should probably be called add_constraint_edge_nonintersecting and add_constraint_nonintersecting, accompanied by their additional intersecting functions that require the above trait bound. This forces users to read the docs which sounds like the best way to explain the splitting behavior.

In general, this is a great feature request which is not too hard to implement (I just have not thought about it yet). This should be part of Spade 2.0, but it will take some time until I can do that. If you require this now, I can point you in the right directions on how this could be implemented.

[Kruptein]

I can definitely wait! I have a bit of an atypical setup in which I currently use a manually ported version of the relevant cgal code (not in rust) and saw your library and was interested in how it would compare, given that my own port is a pretty ugly straight up copy of the cgal code with its cpp mannerisms, whereas this looks pretty clean.

So don't feel rushed to implement this.

[Stoeoef]

I currently use a manually ported version of the relevant cgal code (not in rust) and saw your library

Oh, I can relate to that! The burden that interfacing cpp introduced was the major reason why I even began with Spade. I'll keep this issue update, but as said, this will take likely several months.

[Kruptein]

All fine, thanks for the quick responses!