-
Notifications
You must be signed in to change notification settings - Fork 943
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
@turf/booleanCrosses #796
@turf/booleanCrosses #796
Conversation
} | ||
throw new Error('feature2 ' + type2 + ' geometry not supported'); | ||
default: | ||
throw new Error('feature1 ' + type1 + ' geometry not supported'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
type1
cannot be Point/Polygon/MultiLineString? or you are still working on this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Crosses only supports a very limited set of types, see this link. So as far as I'm concerned I think they're all covered off
👍 that's great that we've got Shapely validation, do you have that code on GitHub anywhere?
|
if (i2 === 0 || i2 === lineString.coordinates.length - 2) { | ||
incEndVertices = false; | ||
} | ||
if (isPointOnLineSegment(lineString.coordinates[i2], lineString.coordinates[i2 + 1], multiPoint.coordinates[i], incEndVertices)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this excluding both end points of both end segments? Shouldn't it just be the actual LineString
end points?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ooo yeah that is a good pickup, a slight modification is needed on the isPointOnLineSegment
function
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
actually now I remember why I did this, I worked out that this didn't matter as the actual 2nd vertex get's picked up in the second segment.
if (i2 === 0 || i2 === lineString2.coordinates.length - 2) { | ||
incEndVertices = false; | ||
} | ||
if (isPointOnLineSegment(lineString1.coordinates[i], lineString1.coordinates[i + 1], lineString2.coordinates[i2], incEndVertices)) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are you checking that the line segment 1 end points fall on line segment 2? cross
only requires that they share some but not all interior points and that the intersections be points. They don't have to be the vertex points.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah ok so I think here Im just checking that the point of intersection (or one of them) occurs somewhere other than the very end of the line.
Gday @dpmcmlxxvi Thanks for the review. Perhaps the best thing to do is if you've got a concern is perhaps add some more test cases and we'll see how they come out. |
@rowanwins Will do. It maybe a little bit before I get some time to work on it but will work on putting some tests together. |
@rowanwins @dpmcmlxxvi As for the types, shouldn't the opposite input types also be valid? Feature1 => Feature2
Question: Shouldn't we return |
Agreed that the opposite input types are valid and should be allowed. Should be easy enough to implement. Use same functions just flip the On the return value. I can go either way. I do think there is some value to the way @rowanwins has it now. It might be helpful to make a distinction between having valid vs. invalid inputs. Returning |
I think if we include the reverse inputs we will have very little "invalid" input types. Ex: Point => Point - should be invalid since two points cannot cross each other. |
@rowanwins FYI: Going to include your shapely script into |
Gday @DenisCarriere Good thinking, it looks like the inverse can be covered in |
@rowanwins Wow, this actually worked, I was able to include the shapely tests directly in the Tape tests. glob.sync(path.join(__dirname, 'test', 'true', '*.geojson')).forEach(filepath => {
const {name} = path.parse(filepath);
const geojson = load.sync(filepath);
const [feature1, feature2] = geojson.features;
if (process.env.SHAPELY) shapely('crosses', feature1, feature2).then(result => t.true(result, '[true] shapely - ' + name));
t.true(crosses(feature1, feature2), '[true] ' + name);
}); Just make sure you define your environment variable as |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍 Looks good
Merging, all the tests pass (including Shapely results). We can always improve this library by adding more test fixtures, so far it looks good to me. |
npm test
at the sub modules where changes have occurred.npm run lint
to ensure code style at the turf module level../scripts/generate-readmes
to createREADME.md
.package.json
using "Full Name <@github Username>".Gday @DenisCarriere
Well I think this is hopefully almost done.
The benchmark results are looking not too bad although I think our line intersections algorithm could be improved
booleanCrosses
, as 'crosses' (rather than cross) is the name of the predicate everywhere else