Closed FObermaier closed 3 years ago
Thanks for the comments.
InherentScaleFilter
is so slow as to be essentially useless. I no longer recommend using it. So yes this would be a good enhancement at some point, but not essential for this codebasenextResult
and setNextResult
? There is some logic to that. My original thinking was that it's nicer to have the setResultXXX
methods sort beside one another alphabetically. And I'm keen to hear how OverlayNG works in NTS! Be sure and try out the recent addition of SnappingNoder
- it seems to solve all robustness problems with no impact on performance.
Are you suggesting using e.g.
nextResult
andsetNextResult
?
Yes, when porting I was wondering whether those refer to the same thing. In C# we use properties for these simple functions, which makes using different names awkward.
And I'm keen to hear how OverlayNG works in NTS!
This is currently work in progress: https://github.com/NetTopologySuite/NetTopologySuite/pull/412
Are you suggesting using e.g.
nextResult
andsetNextResult
?Yes, when porting I was wondering whether those refer to the same thing. In C# we use properties for these simple functions, which makes using different names awkward.
I'll change the setter names.
This is currently work in progress: NetTopologySuite/NetTopologySuite#412
Thanks. Just be aware that the code hasn't been officially released yet, so there may well be more renaming and refactoring.
Setter names changed: https://github.com/dr-jts/jts/commit/fc6c47d1d0d23496826d8777e036a585587eee3d
While porting the overlay-sr branch to NetTopologySuite I came across some issues which I'm going to report here:
nextResult()
andsetResultNext(...)
should be aligned, same fornextResultMax()
andsetResultNextMax(...)
.