Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

buildvrt: add "common" value to "-resolution" argument #11497

Open
dbaston opened this issue Dec 15, 2024 · 2 comments
Open

buildvrt: add "common" value to "-resolution" argument #11497

dbaston opened this issue Dec 15, 2024 · 2 comments
Assignees

Comments

@dbaston
Copy link
Member

dbaston commented Dec 15, 2024

Feature description

I am using gdalbuildvrt to mosaic several tiles from the Copernicus 30m global DEM. The horizontal resolution of this dataset varies by tile. When using gdalbuildvrt to mosaic adjacent tiles with 3-second and 5-second horizontal resolutions, I need to use a horizontal resolution of 1 second, but none of the automatic options available with -resolution can return this value.

I am thinking of implementing -resolution=common, which would attempt to calculate a resolution that can be multiplied by an integer to arrive at both of the input resolutions. An example implementation in Python:

import pytest
import fractions
import math

def common_res(a, b):
    frac_a = fractions.Fraction(a).limit_denominator(10000)
    frac_b = fractions.Fraction(b).limit_denominator(10000)

    common_denom = math.lcm(frac_a.denominator, frac_b.denominator)

    num_a = frac_a.numerator * int(common_denom / frac_a.denominator)
    num_b = frac_b.numerator * int(common_denom / frac_b.denominator)

    common_num = math.gcd(num_a, num_b)

    return common_num / common_denom

@pytest.mark.parametrize("a,b,expected", [
    (5/3600, 3/3600, 1/3600),
    (5, 3, 1),
    (5/3600, 2.5/3600, 2.5/3600),
    (1/10, 1, 1/10),
    (1/10, 1/3, 1/30),
    (1/17, 1/13, 1/221), 
    (1/17, 1/3600, 1/61200),
    ])
def test_common_res(a, b, expected):
    assert common_res(a, b) == expected

The key piece here is the Fraction.limit_denominator method. This could be adapted from CPython or other implementations such as this one.

If this seems like an appropriate addition, I can go ahead and implement it. We would probably want some guardrails to prevent disaggregation by more than a factor of N. This also fails to consider rasters whose resolutions may be "compatible" but whose origin points make them not so.

Additional context

No response

@rouault
Copy link
Member

rouault commented Dec 15, 2024

sounds like a good idea

@jratike80
Copy link
Collaborator

Agreed, good idea. The GDIWG elevation and orthophoto products also change the horizontal resolution at some latitudes.

@dbaston dbaston self-assigned this Dec 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants