[SEDONA-251] Add raster type to Sedona

[umartin]

Did you read the Contributor Guide?

• Yes, I have read Contributor Rules and Contributor Development Guide

Is this PR related to a JIRA ticket?

• Yes, the URL of the associated JIRA ticket is https://issues.apache.org/jira/browse/SEDONA-251. The PR name follows the format [SEDONA-XXX] my subject.

What changes were proposed in this PR?

This PR adds a raster type to Sedona and some basic functions using the raster type.

How was this patch tested?

Unit tests added

Did this PR include necessary documentation updates?

• Yes, I am adding a new API. I am using the [current SNAPSHOT version number]

[jiayuasu]

@umartin

Martin, thanks for this great contribution! Your insights are always helpful to this community! I am Ok with this major change to Sedona Raster module. I think this will make everything easier in Sedona raster. A few more questions:

1. With this new raster implementation, is it possible that we can easily create similar PostGIS raster functions in Sedona? (https://postgis.net/docs/RT_reference.html)
2. Is it possible that we can write GeoTiff DataFrame back to disk, e.g., RS_AsTiff(https://postgis.net/docs/RT_ST_AsTIFF.html)? The current Sedona Raster implementation can write raster back to GeoTiff: https://sedona.apache.org/latest-snapshot/api/sql/Raster-loader/#geotiff-dataframe-writer
3. Is it possible that in the future PRs, we move the existing RS function implementation to this new Raster UDT? Or do you think we should just leave them as is?

@kanchanchy Kanchan, downstream projects such as GeoTorchAI (https://github.com/DataSystemsLab/GeoTorchAI) heavily depends on Sedona raster funcs. What are the most important RS functions that are used by GeoTorchAI?

[umartin]

Thank you @jiayuasu !

1. Yes! Now we should be able to implement all the raster functions in Postgis.
2. I think we can adapt the GeoTiff writer to work with rasters as well as the current double arrays. We just need to figure out exactly how that would work from a user perspective. I'll start a discussion on the mailing list about that.
3. I think that the raster functions in this PR and the current ones, that operate on bands, are complementary. We just need to implement a few function bridging the two. If we can extract bands from rasters and also create rasters from bands the old and new functions will work well together. There are many examples in Postgis we could use as inspiration: https://postgis.net/docs/RT_ST_AsRaster.html https://postgis.net/docs/RT_ST_AddBand.html https://postgis.net/docs/RT_ST_DumpValues.html https://postgis.net/docs/RT_ST_DumpValues.html

[kanchanchy]

Hi @jiayuasu, some of the important functions used by GeoTorchAI are listed below:
RS_GetBand
RS_Normalize
RS_NormalizedDifference
RS_Append
Although the above-mentioned functions are the most important, GeoTorchAI also uses all other RS_ functions supported by Apache Sedona currently.

[umartin]

Thanks for the feedback @kanchanchy!

I don’t see a need to break any of the existing api:s. Where it makes sense, some of the current RS functions could be extended to support both raster and arrays of double. Just like ST_GeomFromWKB supports both binary and string input.

The way I see it is that the new raster type would only add new functionality, not remove or break any existing api.

[jiayuasu]

@umartin Thanks, Martin. I will merge this PR and let's start the discussion in the mailing list :-)

BTW, maybe I should add the new geotools dependency to https://github.com/jiayuasu/geotools-wrapper?

[umartin]

Yes, you're right, geotools-wrapper should be updated too. I also noticed that Sedona and geotools-wrapper are on different geotools versions. I ran tests locally with geotools 28.2 and they all passed. Maybe should upgrade both Sedona and geotools-wrapper to 28.2?