Is your feature request related to a problem?
RS_MapAlgebra runs a Jiffle script per pixel. It has served as Sedona's general raster processing primitive, but it carries costs that a Python UDF does not:
- Jiffle is a language users have to learn, documented outside Sedona, and used nowhere else in the project.
- It pulls in
jt-jiffle-language plus an antlr and janino shading block in common/pom.xml that exists solely to stop janino colliding with Spark's copy in the REPL (RS_MapAlgebra for raster processing #1945).
- It is limited to per-pixel arithmetic — anything reading a neighbourhood, classifying, or calling a library cannot be expressed in it.
Python UDFs over rasters now cover the same ground and more. Raster input has been supported since 1.6.0, and returning a raster landed in #2956 for 1.9.1, so a UDF can do everything RS_MapAlgebra does while also reaching NumPy, SciPy, scikit-learn, and rasterio.
Describe the solution you'd like
Deprecate RS_MapAlgebra in favour of Python UDFs, following the precedent set by ST_Envelope_Aggr in 1.8.1: a documented deprecation notice, with the function left registered and working. The notice states that the function will be removed in a future version so users know to migrate, but this change removes nothing and alters no behaviour.
Scope:
- Deprecation notices on
Raster-map-algebra.md (and its zh translation), Raster-Map-Algebra-Operators/RS_MapAlgebra.md, and the Raster-Functions.md index row, naming v1.9.1 and pointing at the replacement.
@Deprecated on the MapAlgebra.mapAlgebra overloads in sedona-common.
Two prerequisites, both in flight:
The removal itself — dropping the function along with the Jiffle dependency and its janino shading workaround — is a separate change for a later version, once users have had a release or more to migrate.
Describe alternatives you've considered
Keeping RS_MapAlgebra as a peer option rather than deprecating it. The array-based functions (RS_Add, RS_Multiply, RS_NormalizedDifference, …) already cover simple band arithmetic from SQL, which leaves Jiffle serving only the middle ground between those and a UDF — not enough to justify the dependency and the second scripting language.
Is your feature request related to a problem?
RS_MapAlgebraruns a Jiffle script per pixel. It has served as Sedona's general raster processing primitive, but it carries costs that a Python UDF does not:jt-jiffle-languageplus an antlr and janino shading block incommon/pom.xmlthat exists solely to stop janino colliding with Spark's copy in the REPL (RS_MapAlgebra for raster processing #1945).Python UDFs over rasters now cover the same ground and more. Raster input has been supported since 1.6.0, and returning a raster landed in #2956 for 1.9.1, so a UDF can do everything
RS_MapAlgebradoes while also reaching NumPy, SciPy, scikit-learn, and rasterio.Describe the solution you'd like
Deprecate
RS_MapAlgebrain favour of Python UDFs, following the precedent set byST_Envelope_Aggrin 1.8.1: a documented deprecation notice, with the function left registered and working. The notice states that the function will be removed in a future version so users know to migrate, but this change removes nothing and alters no behaviour.Scope:
Raster-map-algebra.md(and itszhtranslation),Raster-Map-Algebra-Operators/RS_MapAlgebra.md, and theRaster-Functions.mdindex row, namingv1.9.1and pointing at the replacement.@Deprecatedon theMapAlgebra.mapAlgebraoverloads insedona-common.Two prerequisites, both in flight:
RS_MapAlgebratakes as an argument. That is Python UDF rasters cannot set NODATA, and Python and the JVM disagree about it #3213, and it needs to be fixed before UDFs are a complete replacement.The removal itself — dropping the function along with the Jiffle dependency and its janino shading workaround — is a separate change for a later version, once users have had a release or more to migrate.
Describe alternatives you've considered
Keeping
RS_MapAlgebraas a peer option rather than deprecating it. The array-based functions (RS_Add,RS_Multiply,RS_NormalizedDifference, …) already cover simple band arithmetic from SQL, which leaves Jiffle serving only the middle ground between those and a UDF — not enough to justify the dependency and the second scripting language.