Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Improve BufferedLine geodesic skew compensation

Open
  • Is something wrong?
#60 3 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
25/100
Issue type
Feature
Clarity
Needs clarification
Activity status
Stale
Tech stack
java
Domain
data

Research direction

Start by locating BufferedLineString, BufferedLine, and the expandBufForLongitudeSkew option. Read how the current buffer is expanded for latitude and how linePrimary and linePerp are represented. Done means the two axes account for latitude and line angle separately, the non-perpendicular effect is handled, and end-cap buffering can be omitted without changing the intended geometry.

Written by the indexing model from the issue text.

Description

InternIdea

BufferedLineString expands each of it's BufferedLine's buffer by a fixed amount depending on how close to a pole it is (see the "expandBufForLongitudeSkew" option). But this implementation is poor since it uniformly increases the buffer on both axis by this amount, which might be too much as well. BufferedLine should maintain a distinct buffer distance for both axis, since each axis will have a different stretch factor dependent on not only the latitude but the angle (slope) of the line. For example a vertical line will have the full stretch applied to the "linePrimary" axis, while the "linePerp" will have no stretch. The reverse for a horizontal line. And for in-between (e.g. a 45-degree line), it should be mixed proportionally.

Another adjustment is that linePerp will not be completely perpendicular to linePrimary due to the stretching. Without stretching it's 90 degrees difference but stretch an X and it flattens and the angle isn't 90 any more.

What we do assume here that technically isn't true, is that the stretching is completely uniform.

A side-effect of this feature is that BufferedLine will additionally be usable without an end-cap buffer (i.e. it chops off at both points). So if we want a circular end-cap style we simply need to add a circle shape to the mix without altering BufferedLine.

Dominant language
Java
Stars
961
Forks
173
No merged PRs in 30d

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from locationtech/spatial4j

All issues in locationtech/spatial4j

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.