Currently we do not prune any ST_Intersects(geography, <literal>) expression:
|
/// Our current spatial data pruning implementation does not correctly handle geography data. |
|
/// We therefore only consider geometry data type for pruning. |
|
fn is_prunable_geospatial_literal(literal: &Literal) -> bool { |
|
let Ok(literal_field) = literal.return_field(&Schema::empty()) else { |
|
return false; |
|
}; |
|
let Ok(sedona_type) = SedonaType::from_storage_field(&literal_field) else { |
|
return false; |
|
}; |
|
let matcher = ArgMatcher::is_geometry(); |
|
matcher.match_type(&sedona_type) |
|
} |
We'll need to support this for effective querying of GeoParquet/Parquet files with geography types!
Briefly, I believe this requires exposing a suitable bounder from sedona-s2geography (it is basically getting an S2Region and then getting the latlngrect bounds). We may have to allow setting a geography bounding engine of some kind as a static global to avoid complicating the dependency structure.
Currently we do not prune any
ST_Intersects(geography, <literal>)expression:sedona-db/rust/sedona-expr/src/spatial_filter.rs
Lines 479 to 490 in e49dcc1
We'll need to support this for effective querying of GeoParquet/Parquet files with geography types!
Briefly, I believe this requires exposing a suitable bounder from sedona-s2geography (it is basically getting an S2Region and then getting the latlngrect bounds). We may have to allow setting a geography bounding engine of some kind as a static global to avoid complicating the dependency structure.