Normalize and (slightly) speedup boundary and limit calculations #1167
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Rationale
Projections are currently inconsistent in how they calculate the boundary and projection limits. Some projections calculate the boundary a point at a time and this is slow (though only on the order of tenths of milliseconds). Private variables are named differently, etc.
Try to normalize the calculations by:
transform_points
instead oftransform_point
._ellipse_boundary
forStereographic
even for circular projections. It's twice as fast and higher resolution by default, too.LinearRing
boundaries instead of sometimesLineString
s.Implications
The
Stereographic
boundary is slightly higher resolution in the default case, and all boundaries are rings; this causes a few minor differences in antialiased lines in the test figures. Times for creating the affected projections are approximately 100 microseconds less on my machine (a small benefit, but it's about 30-45% less than the original time.)I'm also trying to write a 'How to add a projection' doc, so the more consistency the better.