Even Rouault

> to a stated MAX_Z_ERROR One difficulty is to find that value. For ASCII delivered grids, pending the pain of going back to the original sources, we can see it...

> LERC would not be a find_package. It would be vendored. We'd still need a find_package() even if vendored (which I'm moderately enthusiast about, although not strongly opposed), because packagers...

This feels more like a pyproj bug, than a PROJ one. At least the exception comes from https://github.com/pyproj4/pyproj/blob/42aa92f489bd266749a44cb78101eae28e20f5c3/pyproj/_transformer.pyx#L341

> is it expected for `proj_normalize_for_visualization` convert a `PJ_TYPE_TRANSFORMATION` into `PJ_TYPE_CONCATENATED_OPERATION`? @snowman2 yes, that's exactly how the implementation works: it takes the original transformation and prepends / appends axis swap...

> and it raised the error: `missing required input` proj_coordoperation_is_instantiable() returns that error if the passed PJ* object is NULL.

I've investigated this a bit and the issue stems from the fact that we use the ellipsoidal formulation of oblique mercator even when on a sphere , like here. Most...

> The transform should - as far as I understand - leave the x and y values (mostly?) unchanged, It will definitely modify longitude, latitude to something more complicated, as...

> Is there a workaround or a fallback method to do these conversions, or something as close as possible? none that I can think of. Implementing them shouldn't be too...

I believe one of the major source of slowdown of gdal2tiles is that it requests the data corresponding to a tile into a temporary buffer whose dimension are 4 times...

closing as superseded by the new gdal raster tile application