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

Rasterization: remaining differences from GDAL on grid-aligned inputs

Open
  • Is something wrong?
#3,429 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
45/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
java, python
Domain
computer-graphics, data

Research direction

Start with the grid-aligned cases in this issue, then inspect RasterConstructorsTest.testAsRasterWithRaster and the rasteralgebraTest case using test5.tiff. Replay the cases against GDAL 3.12.4 and rasterio 1.5.1, decide which differences Sedona should follow or document, and add each decided case to test_rasterize_parity.py.

Written by the indexing model from the issue text.

Description

#3425 (#3428) aligns points, grid-aligned polygon edges and boundary-only contact with GDAL's half-open cells. A grid-aligned comparison corpus, replayed against GDAL 3.12.4 (rasterio 1.5.1), still shows the differences below. All of them exist on master already; none were introduced by #3428. Each needs a decision on whether Sedona should follow GDAL.

Unless noted, the grid is 8x8 unit pixels, north-up, origin (0, 8): RS_MakeEmptyRaster(1, 'd', 8, 8, 0, 8, 1, -1, 0, 0, 0). Cells are (column, row).

1. allTouched = false: pixel centres exactly on a polygon edge

POLYGON ((2.5 5.5, 4.5 5.5, 4.5 3.5, 2.5 3.5, 2.5 5.5)) puts pixel centres exactly on all four edges.

  • GDAL: columns 3-4, rows 2-4
  • Sedona: columns 2-4, rows 3-4

The scanline fill resolves a centre on an edge differently from GDAL.

2. allTouched = true: a cell touched only at a polygon vertex

POLYGON ((1 7, 5 7, 3 4, 1 7)): the apex (3, 4) is the top-left corner of cell (3,4), which the polygon touches only at that point.

  • GDAL burns (3,4)
  • Sedona does not

#3120 chose not to follow this. The comment in RasterConstructorsTest.testAsRasterWithRaster describes it as a quirk of GDAL's scan order. GDAL does not burn such cells in every orientation (the #3120 cases match), so this is slope- or direction-dependent on GDAL's side.

3. Lines with allTouched = false: an endpoint on a grid line
Geometry GDAL all_touched=False GDAL all_touched=True Sedona (both)
LINESTRING (1 5, 6 5) (along a row line) columns 1-6 on row 3 columns 1-5 columns 1-5
LINESTRING (0 7, 0 2) (along the left edge) rows 1-6 in column 0 rows 1-5 rows 1-5

GDAL's non-all-touched line burner also burns the cell after an endpoint that lies on a grid line. Sedona uses one exact traversal for both modes, matching all_touched=True.

4. allTouched = true: a steep edge passing exactly through lattice corners

The zone in rasteralgebraTest "RS_ZonalStats - Raster with no data" (test5.tiff, 0.25-degree grid):

  • Sedona counts 14366 with allTouched = true
  • GDAL counts 14357

The nine extra cells lie along the left edge, which has slope 19/5 and passes exactly through a lattice corner every 5 columns / 19 rows. They are cells (3,179), (8,160), (13,141), ... (43,27). With allTouched = false there are ten similar centre-on-edge differences.

5. Pixel sizes with no exact binary representation (expected, probably no action)

On a 1/3600-degree grid, a coordinate that lies on a grid line is resolved by GDAL in floating point and by Sedona with the exact decimal arithmetic it uses to snap extents. For example, on the tile at origin (-180 + 822/3600, 60 - 546/3600), POINT (-179.77083333333334 59.84736111111111):

  • GDAL: (2,3)
  • Sedona: (3,3)

Both burn exactly one cell. Matching GDAL bit for bit would mean reproducing its internal arithmetic, which is not a stable target: plain double arithmetic and GDAL's inverse geotransform each match GDAL on some of these cases and not others.

Suggested next steps
  • Decide 1-3 (follow GDAL, or document the difference).
  • Look at 4, which looks like a traversal or fill tie at exact lattice crossings.
  • Add each decided case to test_rasterize_parity.py.
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.