Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Optimize point-in-circle (geodesic) calc tracking results of previous results

Abierto
  • ¿Algo no está bien?
#58 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
25/100
Tipo de issue
Refactorización
Claridad
Necesita aclaración
Estado de actividad
Estancado
Stack tecnológico
java
Área
performance

Línea de trabajo

Empiece leyendo las comprobaciones de las relaciones de Circle y las llamadas a DistanceCalculator.withinDistance descritas en el issue. Mida si el rectángulo interno de 45 grados mejora el rendimiento geodésico antes de considerar el seguimiento incremental de las fronteras interior y exterior; cualquier estado mutable de la forma debe tener un plan de seguridad de hilos o de API.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

InternIdea

The Circle shape determines the relationship between another shape (notable a point or rectangle) with itself (e.g. Within, Disjoint, ...). To do this, usually needs to call DistanceCalculator.withinDistance(point, point, distance) one or more times. For the geodesic implementation, the distance calculation is somewhat expensive.

Milestone 1: An idea here is to first use the internal 45-degree rectangle to more quickly calculate if the point is within that. It's in effect an inner-box (versus an outer bounding box).

Milestone 2. If measurements show milestone 1 to be faster then proceed here. As withinDistance() needs to be called and returns true, expand the inner box creating a sort of inner convex hull polygon shape, starting with the 45-degree inner box from before. But don't track "too many" points. When withinDistance() returns false, an outer polygon frontier can be incrementally built similarly to the inside. To constrain the detail, for each quadrant of the circle, you might add no more than say 64 frontier points on each side. So that it's evenly distributed, you might furthermore limit points being added to a fixed 1/64th band per quadrant.

A problem with Milestone 2 is that it would make the shape mutable, to some extent. Some care would be needed to make it thread-safe or devise some other API approach.

Lenguaje dominante
Java
Estrellas
962
Forks
174
Sin PR fusionados en 30 d

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de locationtech/spatial4j

Todos los issues de locationtech/spatial4j

Issues similares

Más issues de Java

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.