paleolimbot opened a new issue, #714: URL: https://github.com/apache/sedona-db/issues/714
Once the worst of the performance issues are solved in #139 / #708, we can think about how to wire in the Geography data type into the spatial join. The simplest form of this would be to wire through the (currently non-existent) tool in sedona-s2geography that produces a bounding rectangle from a geography and treat anything crossing the antimeridian as having a longitude range of -180...180. This probably plugs in directly to the existing infrastructure but does a very bad job if there are any antimeridian crossing geographies (many, many false positive bbox intersections). The next simplest form of this would be to split the rectangle on the antimeridian and allow >1 rectangle to exist in the rtree index for each item in the build side. I think I remember seeing code when I reviewed the join implementation that supports this but I will have to revisit that piece. This version will do a poor job around polar regions (although this could be worked around by splitting up the bbox into a larger number of component bboxes if >2 rectangles can someday be supported). A third thing we can do is just use a geography-compatible index. The one in S2 would be a S2CellIndex, where each element is represented by a collection of S2CellIds. This is probably not something worth doing for the initial implementation but I did want to mention it as an option since I recently found it in the S2 geometry code. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
