Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

RS_PixelAsPoint raises out of grid where RS_PixelAsCentroid and RS_PixelAsPolygon extrapolate

Closed Beginner friendly
  • Is something wrong?
#3,395 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
75/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
java, sql
Domain
backend, databases

Research direction

The issue is in common/src/main/java/org/apache/sedona/common/raster/PixelFunctions.java. Look at getPixelAsPoint and change it to call RasterUtils.getWorldCornerCoordinates instead of getWorldCornerCoordinatesWithRangeCheck. Update the test in common/src/test/java/org/apache/sedona/common/raster/FunctionsTest.java to expect the extrapolated point, not an exception. Then update the documentation for RS_PixelAsPoint to match the other functions.

Written by the indexing model from the issue text.

Description

Expected behavior

RS_PixelAsPoint, RS_PixelAsCentroid and RS_PixelAsPolygon are one family — the same grid coordinate interpreted as a corner, a centre and a footprint — so they should agree on what an out-of-grid coordinate means.

Actual behavior

Only RS_PixelAsPoint rejects one. On a 2×3-pixel raster at (100, 500) with Sedona 1.9.1:

RS_PixelAsPoint(rast, 1, 1)    -> POINT (100 500)
RS_PixelAsPoint(rast, 0, 0)    -> IndexOutOfBoundsException:
                                  Specified pixel coordinates (0, 0) do not lie in the raster
RS_PixelAsCentroid(rast, 0, 0) -> POINT (99 501.5)
RS_PixelAsPolygon(rast, 0, 0)  -> POLYGON ((98 503, 100 503, 100 500, 98 500, 98 503))

The two siblings extrapolate along the geotransform without complaint. Note the polygon's first corner, (98 503): that is exactly the point RS_PixelAsPoint(0, 0) refuses to return. The value is already computed and returned by a sibling function on the same input — only this one entry point declines to hand it over.

This is documented, so it reads as deliberate rather than accidental, but the docs state the inconsistency plainly:

  • RS_PixelAsPoint: "If the pixel coordinates specified do not exist in the raster (out of bounds), RS_PixelAsPoint throws an IndexOutOfBoundsException."
  • RS_PixelAsPolygon and RS_PixelAsCentroid: "If colX and rowY are out of bounds for the raster, they are interpolated assuming the same skew and translate values."

Cause

One call site in common/src/main/java/org/apache/sedona/common/raster/PixelFunctions.java. getPixelAsPoint uses the range-checking helper:

Point2D point2D = RasterUtils.getWorldCornerCoordinatesWithRangeCheck(raster, colX, rowY);

while getPixelAsPolygon uses the unchecked one:

Point2D point2D1 = RasterUtils.getWorldCornerCoordinates(raster, colX, rowY);

and getPixelAsCentroid delegates to getPixelAsPolygon, inheriting the unchecked behaviour. getWorldCornerCoordinatesWithRangeCheck (common/src/main/java/org/apache/sedona/common/utils/RasterUtils.java) has exactly one caller — getPixelAsPoint.

Proposed fix

Drop the range check so getPixelAsPoint matches its siblings, extrapolating along the geotransform. That direction is the non-breaking one: it turns an exception into a value, where the reverse would break existing RS_PixelAsCentroid/RS_PixelAsPolygon callers who rely on extrapolation today.

That would mean:

  • getPixelAsPoint calls RasterUtils.getWorldCornerCoordinates, leaving getWorldCornerCoordinatesWithRangeCheck unused (remove it, or keep it if another caller is planned).
  • testPixelAsPointOutOfBounds in common/src/test/java/org/apache/sedona/common/raster/FunctionsTest.java currently pins the exception, and would assert the extrapolated point instead.
  • The RS_PixelAsPoint doc line changes to match the wording already used by the other two.

I am happy to open the PR if the direction sounds right. The alternative — making all three raise — is defensible on the grounds that an out-of-grid coordinate is usually a caller error, but it is a breaking change for two functions rather than a widening of one, and it would leave RS_PixelAsPolygon unable to return a footprint it can compute perfectly well.

For cross-implementation context: SedonaDB extrapolates for all three, so aligning this way would also close a divergence between the two engines.

Dominant language
Java
Stars
2.4k
Forks
787
Avg merge
1d 23h
Merged PRs (30d)
51

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from apache/sedona

All issues in apache/sedona

Similar issues

More Java issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.