Skip to content
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

improve sanity check for geodesic distance calc #7457

Conversation

nmschulte
Copy link
Contributor

@nmschulte nmschulte commented Jan 3, 2019

https://groups.google.com/forum/#!topic/cesium-dev/uTaQKBSzxCU

Based upon the discussion linked above, I think this is a small improvement to the current logic. The commit message has the details and this description has more: https://en.wikipedia.org/wiki/Geodesics_on_an_ellipsoid#Behavior_of_geodesics

(commit message)

guard Vincenty's inverse computation (surface distance) by the cut locus specific to the ellipsoid (assumed as oblate given min/max radii)

(Wikipedia extract; emphasis mine)

Gauss (1828) showed that, on any surface, geodesics and geodesic circle intersect at right angles. The red line is the cut locus, the locus of points which have multiple (two in this case) shortest geodesics from A. On a sphere, the cut locus is a point. On an oblate ellipsoid (shown here), it is a segment of the circle of latitude centered on the point antipodal to A, φ = −φ₁. The longitudinal extent of cut locus is approximately λ₁₂ ∈ [π − f π cosφ₁, π + f π cosφ₁]. If A lies on the equator, φ₁ = 0, this relation is exact and as a consequence the equator is only a shortest geodesic if |λ₁₂| ≤ (1 − f)π. For a prolate ellipsoid, the cut locus is a segment of the anti-meridian centered on the point antipodal to A, λ₁₂ = π, and this means that meridional geodesics stop being shortest paths before the antipodal point is reached.

guard Vincenty's inverse computation (surface distance) by the cut locus
specific to the ellipsoid (assumed as oblate given min/max radii)
@cesium-concierge
Copy link

Thanks for the pull request @nmschulte!

  • ✔️ Signed CLA found.
  • CHANGES.md was not updated.
    • If this change updates the public API in any way, please add a bullet point to CHANGES.md.
  • ❔ Unit tests were not updated.
    • Make sure you've updated tests to reflect your changes, added tests for any new code, and ran the code coverage tool.

Reviewers, don't forget to make sure that:

  • Cesium Viewer works.
  • Works in 2D/CV.
  • Works (or fails gracefully) in IE11.

I am a bot who helps you make Cesium awesome! Contributions to my configuration are welcome.

🌍 🌎 🌏

@@ -171,14 +171,18 @@ define([
ellipsoidGeodesic._uSquared = uSquared;
}

//>>includeStart('debug', pragmas.debug);
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I wonder about these scratch variables:
Why do these scratch variables live outside the only scope they're used?
Why use scratch variables like this?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

While debugging (the web worker) I ran into a case where the "subdivide heights" scratch array had a zero-length even though the code that was being debugged had presumably just initialized it... I reproduced it once after a refresh (left the debugger open). I've noticed strange behavior while debugging web workers with Chrome, so it's possible it's an artifact of that and not an issue with the logic (shared scratch) and some kind of race condition (between worker/worker or worker/main -- ... apologies I'm not well versed here).

Copy link
Contributor

Choose a reason for hiding this comment

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

The scratch variables are at this scope so they can be reused each time the function is called instead of creating new instances each time. This is something we do commonly for performance. See https://github.com/AnalyticalGraphicsInc/cesium/tree/master/Documentation/Contributors/CodingGuide#result-parameters-and-scratch-variables

So you'll need to remove the pragmas here

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Same here with adding the pragma block: these scratch variables are only used for the debug check.

@nmschulte
Copy link
Contributor Author

Digging a bit more this idea may be misguided, even though Cesium seems to render things fine for my case. I think the tolerance here is due to the nature of the approximation of the integral solution of Vincenty's formula, not necessarily the (maximum) locus length. Please correct me if so.

var includedAngle = Math.abs(Math.abs(Cartesian3.angleBetween(startCartesian, endCartesian)) - CesiumMath.PI);
// maxLambda is an approximation, assuming an oblate ellipsoid, and zero latitude (equatorial; phi = 0)
var maxLambda = (1 - (ellipsoid.maximumRadius - ellipsoid.minimumRadius) / ellipsoid.maximumRadius) * CesiumMath.PI;
Check.typeOf.number.lessThanOrEquals('value', includedAngle, maxLambda);
Copy link
Contributor

Choose a reason for hiding this comment

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

This Check call should be the only thing inside the debug pragmas here. Everything between //>>includeStart and //>>includeEnd will be removed from the code in the minified release version, so you don't want to have any logic included in that section. It's only for throwing DeveloperErrors

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I moved that logic into the pragma block because it is only used for the check.

@hpinkos
Copy link
Contributor

hpinkos commented Jan 3, 2019

@shunter did you want to take a look at this?

@cesium-concierge
Copy link

Thanks again for your contribution @nmschulte!

No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?

I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

@hpinkos
Copy link
Contributor

hpinkos commented Feb 4, 2019

@shehzan10 could you give this a review?

@shehzan10
Copy link
Member

Digging a bit more this idea may be misguided, even though Cesium seems to render things fine for my case. I think the tolerance here is due to the nature of the approximation of the integral solution of Vincenty's formula, not necessarily the (maximum) locus length. Please correct me if so.

I think either @shunter or @fstoner have a better handle on this question than I do.

This code looks fine to me. On the default ellipsoid, maxLambda=3.131059488236545
thus the change is going from 0.0125 to 0.010533165353248108.

When I was doing the ellipsoid rhumb line code, I had a similar question about how 0.0125 was chosen, but this PR has a reasoning behind it. It was also brought up (tangentially) here: #7484 (comment).

So the only thing I would request is that this change should be applied to EllipsoidRhumbLine as well https://github.com/AnalyticalGraphicsInc/cesium/blob/master/Source/Core/EllipsoidRhumbLine.js#L141.

@cesium-concierge
Copy link

Thanks again for your contribution @nmschulte!

No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?

I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

@hpinkos
Copy link
Contributor

hpinkos commented Mar 7, 2019

@nmschulte can you merge in master? I think these changes look fine, I'll get them merged in this month after the branch is updated. Thanks!

@hpinkos
Copy link
Contributor

hpinkos commented Mar 7, 2019

Please also add a unit test

@nmschulte
Copy link
Contributor Author

@nmschulte can you merge in master? I think these changes look fine, I'll get them merged in this month after the branch is updated. Thanks!

Is it a concern if I rebase these changes instead? I can include refactor/changes to update EllipsoidRhumbLine as well.

Please also add a unit test

I'll try my best ;).

I'm still concerned that my logic connecting locus length to the approximation algorithm is incorrect and including this change will cause the formula to diverge (spin-lock/Bad Things™).

idea may be misguided, even though Cesium seems to render things fine for my case. I think the tolerance here is due to the nature of the approximation of the integral solution of Vincenty's formula, not necessarily the (maximum) locus length.

@hpinkos
Copy link
Contributor

hpinkos commented Mar 11, 2019

@nmschulte yes, a rebase would be fine.

Thanks for pointing out your concern about locus length. I'm actually not familiar with that at all. @fstoner do you have any insight here?

@cesium-concierge
Copy link

Thanks again for your contribution @nmschulte!

No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?

I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

5 similar comments
@cesium-concierge
Copy link

Thanks again for your contribution @nmschulte!

No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?

I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

@cesium-concierge
Copy link

Thanks again for your contribution @nmschulte!

No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?

I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

@cesium-concierge
Copy link

Thanks again for your contribution @nmschulte!

No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?

I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

@cesium-concierge
Copy link

Thanks again for your contribution @nmschulte!

No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?

I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

@cesium-concierge
Copy link

Thanks again for your contribution @nmschulte!

No one has commented on this pull request in 30 days. Maintainers, can you review, merge or close to keep things tidy?

I'm going to re-bump this in 30 days. If you'd like me to stop, just comment with @cesium-concierge stop. If you want me to start again, just delete the comment.

@hpinkos
Copy link
Contributor

hpinkos commented Sep 18, 2019

Thanks for the PR @nmschulte, but I'm going to close this due to inactivity. This check is probably fine, but it's been difficult to verify and get this merged.

@hpinkos hpinkos closed this Sep 18, 2019
@cesium-concierge
Copy link

Congratulations on closing the issue! I found these Cesium forum links in the comments above:

https://groups.google.com/forum/#!topic/cesium-dev/uTaQKBSzxCU

If this issue affects any of these threads, please post a comment like the following:

The issue at #7457 has just been closed and may resolve your issue. Look for the change in the next stable release of Cesium or get it now in the master branch on GitHub https://github.com/AnalyticalGraphicsInc/cesium.

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.

None yet

4 participants