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

simplify GeodesicPoly* classes a lot #4

Draft
wants to merge 2 commits into
base: master
Choose a base branch
from
Draft

simplify GeodesicPoly* classes a lot #4

wants to merge 2 commits into from

Conversation

johnd0e
Copy link
Collaborator

@johnd0e johnd0e commented Aug 24, 2019

Based on ideas from IITC-CE/ingress-intel-total-conversion#232

Main idea: do not store intermediate points.
Instead they are calculated on every projection (which typically occurs on zoom/viewreset).

  • greatly simplify classes, and increase compatibility with L.Polyline-related routines (especially 3rd-party).
  • changes in performance is unmeasured yet
    • memory footprint is lower
    • recalculations may be more frequent (unsure)
But besides mentioned benefits there is also plenty space for future improvement
  • depend on zoom
  • depend on map bounds
    • include lines/bounds intersections to points
    • clip to bounds (not calculate invisible parts)
    • more: see Geodesic accuracy #2

@johnd0e johnd0e mentioned this pull request Aug 24, 2019
@johnd0e
Copy link
Collaborator Author

johnd0e commented Aug 24, 2019

This PR introduces catching simplification, but we cannot merge it until we'll make tests to make sure that performance gets better with it.

@MysticJay
Copy link

To estimate on better performance:
Hard numbers in seconds depend too much on external parameters.
Instead count the number of calculations done and log the to console.

We know from the old routines that it did devide in to about 5km segments.
We also know that links that would cross map in one additional view around the center are calculated.

If we do not store the invisible nodes (intermediate points) any more, wouldn't that have the same effect as not calculating the "outside current view" areas, with all the negative impact on Map-pan actions.

johndoe added 2 commits February 24, 2020 10:06
do not store intermediate points (recalculate on every projection)
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

2 participants