Raster/vector join: densify footprint for cross-CRS accuracy

[james-willis]

The raster–vector join reprojects the raster footprint (convex hull of the corners, or envelope) with straight chords and no edge densification, so cross-CRS results can under-/over-cover along curved edges. Densifying the footprint edges (~10 points) before reprojection would improve accuracy for large-extent or very-different-CRS pairs.

This tracks the Sedona (Spark) side. The SedonaDB side: apache/sedona-db#1076.

[james-willis]

For reference, the SedonaDB side implemented this by densifying each footprint edge (~10 points) in the raster's native CRS before reprojecting — so the reprojected footprint follows the curve rather than a straight chord between the four corners. A similar densify before the WGS84 envelope/hull reprojection would improve cross-CRS accuracy on the Spark side.

[jiayuasu]

It seems to me that this is to combat the impact of spherical edges of raster convex hull. Should we solve this problem by introducing Geography type bounding box / convex hull of the raster, instead of simulating the situation by densifying the edges?

CC @paleolimbot

[paleolimbot]

The two are more or less identical with the current set up....in order to generate a Geography convex hull you have to add points along the edges. We have that version parameterized with an accuracy in meters in SedonaDB (ST_TessellateGeog()), so at least you get to choose the error you're comfortable with.

The current version of that is still not quite as accurate as densifying edges in the original coordinate system (because the tessellation is only implemented from planar lon/lat to spherical lon/lat...it's possible to consider a different coordinate system but it isn't there yet).

In other words, it's not the spherical edges of the raster convex hull, it's the transformation between coordinate systems that render four points inadequate to calculate potential intersection. 10 points along each edge is an easy way to improve accuracy without changing behaviour for the common case...if we want to do the Geography thing we can invent a new predicate (RS_DWithin()?) that takes into account error tolerance.