"Side location conflicts" in geometry parsing
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 35/100
Línea de trabajo
Reproduce el fallo del polígono de FootprintServiceTest.solrTest y sigue JtsGeometry.java a través de cutUnwrappedGeomInto360 y los métodos unwrapDateline. Comprueba el TODO indicado y el stack trace de TopologyException; se considera terminado cuando este polígono del Polo Sur/dateline se convierte sin el side location conflict y sigue siendo válido.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
Discovered while using solr-spatial, the following spatial polygon becomes invalid:
POLYGON ((-15.9894 -65.2345, -4.5951 -69.5654, 9.3512 -72.4781, 26.2688 -74.0308, 44.6448 -74.0661, 47.3341 -78.1059, 51.7677 -81.3178, 58.1878 -83.606, 66.9686 -85.1874, 106.2119 -87.2101, 161.1218 -86.5675, 180 -87.4608, 180 -90, -180 -90, -180 -87.4608, -120.1955 -87.5958, -99.3114 -86.8001, -85.1881 -85.4186, -76.624 -83.5204, -70.7275 -80.7504, -66.6851 -76.7469, -63.8756 -70.899, -37.2776 -69.837, -25.9748 -67.9771, -15.9894 -65.2345))
If you were to plot this on a globe, it would look like a satellite's swath that went over the South Pole, which may be causing some issues. It shape "crosses" the dateline at 180 -87.406, but we don't split it, instead we go 'down' 180 -90, then across the globe to -180 -90 and continue the shape so it's not a multipolygon but rather a single polygon.
The polygon that the spatial4j is working on becomes:
spatial4j: POLYGON ((-15.9894 -65.2345, -4.5951 -69.5654, 9.3512 -72.4781, 26.2688 -74.0308, 44.6448 -74.0661, 47.3341 -78.1059, 51.7677 -81.3178, 58.1878 -83.606, 66.9686 -85.1874, 106.2119 -87.2101, 161.1218 -86.5675, 180 -87.4608, 180 -90, 180 -90, 180 -87.4608, 239.80450000000002 -87.5958, 260.6886 -86.8001, 274.8119 -85.4186, 283.376 -83.5204, 289.2725 -80.7504, 293.31489999999997 -76.7469, 296.1244 -70.899, 322.7224 -69.837, 334.0252 -67.9771, 344.0106 -65.2345))
This happens during the 'unwrapDateline' methods. I think there is a suggestion in the code itself about this possibly being an issue:
//TODO TEST THIS! Maybe bug if doesn't cross but is in another page?
now if i manually 'fix' the polygon and add in a bunch of filler points between the -180 -90 and 180 -90 points, i can get it to work:
POLYGON((-15.9894 -65.2345, -4.5951 -69.5654, 9.3512 -72.4781, 26.2688 -74.0308, 44.6448 -74.0661, 47.3341 -78.1059, 51.7677 -81.3178, 58.1878 -83.606, 66.9686 -85.1874, 106.2119 -87.2101, 161.1218 -86.5675, 180 -87.4608, 180 -90, 120 -90, 60 -90, 0 -90, -60 -90, -120 -90, -180 -90, -180 -87.4608, -120.1955 -87.5958, -99.3114 -86.8001, -85.1881 -85.4186, -76.624 -83.5204, -70.7275 -80.7504, -66.6851 -76.7469, -63.8756 -70.899, -37.2776 -69.837, -25.9748 -67.9771, -15.9894 -65.2345))
but it's hard to modify the code generating this because we use a Ramer–Douglas–Peucker algorithm to remove unneeded points- which doesn't keep the points between the -180 -90 and 180 -90 coordinates.
Below is the full stacktrace i'm generating:
com.vividsolutions.jts.geom.TopologyException: side location conflict [ (-15.9894, -65.2345, NaN) ]
at com.vividsolutions.jts.geomgraph.EdgeEndStar.propagateSideLabels(EdgeEndStar.java:300)
at com.vividsolutions.jts.geomgraph.EdgeEndStar.computeLabelling(EdgeEndStar.java:139)
at com.vividsolutions.jts.geomgraph.DirectedEdgeStar.computeLabelling(DirectedEdgeStar.java:127)
at com.vividsolutions.jts.operation.overlay.OverlayOp.computeLabelling(OverlayOp.java:373)
at com.vividsolutions.jts.operation.overlay.OverlayOp.computeOverlay(OverlayOp.java:173)
at com.vividsolutions.jts.operation.overlay.OverlayOp.getResultGeometry(OverlayOp.java:127)
at com.vividsolutions.jts.operation.overlay.OverlayOp.overlayOp(OverlayOp.java:66)
at com.vividsolutions.jts.operation.overlay.snap.SnapIfNeededOverlayOp.getResultGeometry(SnapIfNeededOverlayOp.java:96)
at com.vividsolutions.jts.operation.overlay.snap.SnapIfNeededOverlayOp.overlayOp(SnapIfNeededOverlayOp.java:58)
at com.vividsolutions.jts.geom.Geometry.intersection(Geometry.java:1342)
at com.spatial4j.core.shape.jts.JtsGeometry.cutUnwrappedGeomInto360(JtsGeometry.java:468)
at com.spatial4j.core.shape.jts.JtsGeometry.(JtsGeometry.java:65)
at com.spatial4j.core.context.jts.JtsSpatialContext.makeShape(JtsSpatialContext.java:290)
at com.spatial4j.core.context.jts.JtsSpatialContext.makeShape(JtsSpatialContext.java:303)
at gov.nasa.podaac.l2ss.FootprintServiceTest.solrTest(FootprintServiceTest.java:113)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at junit.framework.TestCase.runTest(TestCase.java:164)
at junit.framework.TestCase.runBare(TestCase.java:130)
at junit.framework.TestResult$1.protect(TestResult.java:106)
at junit.framework.TestResult.runProtected(TestResult.java:124)
at junit.framework.TestResult.run(TestResult.java:109)
at junit.framework.TestCase.run(TestCase.java:120)
at org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:131)
at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
- Lenguaje dominante
- Java
- Estrellas
- 962
- Forks
- 174
- Métricas de merge de PR
- Sin PR fusionados en 30 d
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Sin plantilla de pull request
- Leer la guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de locationtech/spatial4j
-
question
Dificultad 5/5 Más de una semana Aptitud para principiantes 20/100
locationtech/spatial4j#233 · 1 comentario ·
-
Validation for self-intersection WKT Multipolygon fails at the WKTReader, while works when wrapped in a `GEOMETRYCOLLECTION`Quizá libre de nuevo Un pull request para esta issue se cerró sin fusionarse. Abiertobug
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
locationtech/spatial4j#232 · 1 comentario ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
locationtech/spatial4j#231 · 1 comentario ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
locationtech/spatial4j#230 · 2 comentarios ·
-
bug
Dificultad 3/5 1-2 días Aptitud para principiantes 45/100
locationtech/spatial4j#227 · 2 comentarios ·
Todos los issues de locationtech/spatial4j
Issues similares
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
apache/skywalking#14120 ·
Los mantenedores suelen responder en 1 día
-
[Feature] 关于启动游戏进度条显示的优化Abiertoenhancement
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
HMCL-dev/HMCL#6943 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 85/100
micronaut-projects/micronaut-core#13677 ·
Los mantenedores suelen responder en 1 día
-
new feature
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 78/100
apache/rocketmq-dashboard#5594 ·
Los mantenedores suelen responder en 3 días