8000 FIX: Fix polyfill bug when vertex latitude exactly matches cell center by nrabinowitz · Pull Request #603 · uber/h3 · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

FIX: Fix polyfill bug when vertex latitude exactly matches cell center #603

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

Merged
merged 3 commits into from
Apr 23, 2022

Conversation

nrabinowitz
Copy link
Collaborator

Fixes #595

The issue here (I think?) is that rays cast directly through a vertex of the polygon were being counted twice, once for each adjoining segment. This uses the same "bias in an arbitrary direction" approach we used for longitude matches, which should also ensure no overlap between contiguous polygons, which I think was previously an issue.

@coveralls
Copy link
coveralls commented Apr 21, 2022

Coverage Status

Coverage increased (+0.002%) to 98.66% when pulling ea14a6b on nrabinowitz:fix-polyfill-issue into 64ffb1e on uber:master.

Comment on lines +98 to +100
if (lat == a.lat || lat == b.lat) {
lat += DBL_EPSILON;
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What happens if the latitude is maximally north already? I assume there won't be any issue here?

Copy link
Collaborator Author
@nrabinowitz nrabinowitz Apr 22, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You may be correct - if we're checking the latlng point [90, 0] (i.e. the north pole), this algorithm will I think fail to contain it in any polygon. But because we're using Cartesian polygons to begin with, there's no pole-enclosing polygon anyway. This is all moot for the polyfill usage, however, because the north pole cell at res 15 has a center latitude of 89.99999581738042, so it's not possible for this issue to arise. If we offered point-in-poly as an external function, this might be an issue, but probably one we could address in documentation.

I suppose we could address this issue with

if (lat > M_PI_2) {
  lat = M_PI_2 - DBL_EPSILON
}

but I don't think this is necessary for our current usage, and not worth the extra branch.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So the lat and lng here is provided by the caller, so this is theoretically a problem, but we just use the centerpoint of the polygon in reality:

if (!pointInsidePolygon(geoPolygon, bboxes, &hexCenter)) {

There might be a problem with pointInsideLinkedGeoLoop, though, since it just uses the first point which could be the northernmost one:

pointInsideLinkedGeoLoop(polygons[i]->first, bboxes[i],

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The pointInsideLinkedGeoLoop function is looking at whether one loop is inside another. So for this issue to occur, you'd need a fairly pathological shape, where not only was one vertex of the outer loop on the north pole, but one vertex of the inner loop was also on the north pole, eg.

image

But again, the loops involved here are derived from H3 cell boundaries, and there is no cell with a center or a vertex on the north pole.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps add a comment explaining the assumption that only cell centers or vertexes are expected to be compared here against the user input?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added a long comment noting the issue.

Comment on lines +98 to +100
if (lat == a.lat || lat == b.lat) {
lat += DBL_EPSILON;
}
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Perhaps add a comment explaining the assumption that only cell centers or vertexes are expected to be compared here against the user input?

8000
@nrabinowitz
Copy link
Collaborator Author

Coverage Status

Coverage decreased (-0.03%) to 98.632% when pulling 6d5d92b on nrabinowitz:fix-polyfill-issue into 64ffb1e on uber:master.

Investigating this fall in coverage - I suspect that some of the "lng == a.lng" cases in tests are now being short-circuited by "lat == a.lat", because the points were equal.

@nrabinowitz
Copy link
Collaborator Author

Ha!

COVERAGE INCREASED (+0.002%) 

Taking the W.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

h3 index for center point is not returned during polyfill
4 participants
0