Skip to content

geotiff: write_geotiff_gpu and to_geotiff disagree on kwarg ordering #1922

@brendancol

Description

@brendancol

to_geotiff and write_geotiff_gpu are documented as parity siblings. The GPU writer's docstring says "Accepted at the signature level for API parity with to_geotiff" for several kwargs. The two signatures put max_z_error and streaming_buffer_bytes in different positions though.

to_geotiff (xrspatial/geotiff/_writers/eager.py:50-67):

..., bigtiff, gpu, streaming_buffer_bytes, max_z_error, photometric, allow_internal_only_jpeg

write_geotiff_gpu (xrspatial/geotiff/_writers/gpu.py:33-49):

..., bigtiff, max_z_error, streaming_buffer_bytes, photometric, allow_internal_only_jpeg

Both kwargs are keyword-only so caller code does not break. The drift surfaces in inspect.signature(), IDE autocomplete, and Sphinx-rendered docs -- the "two writers look identical from outside" promise leaks there.

Proposed fix

Reorder write_geotiff_gpu to match to_geotiff (streaming_buffer_bytes before max_z_error). gpu is the only kwarg to_geotiff has that the GPU entry point does not, so the gap stays in place; everything else after bigtiff lines up.

No deprecation shim needed: both args are keyword-only, defaults are unchanged, behaviour is unchanged.

Detected by

deep-sweep-api-consistency on 2026-05-15.

Severity: MEDIUM (Cat 1 — parameter naming/ordering drift between explicit-parity siblings).

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type
    No fields configured for issues without a type.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions