rasql - project() to specified geo axes resolutions

[Bang Pham Huu]

​project operator should support projecting a 2D array to a target CRS with specified axes resolutions for the target CRS (like the -tr option in ​gdalwarp).

The new project() signature would look like

project( mddExpr, boundsIn, crsIn, boundsOut, crsOut,
         axisResolution1, axisResolution2, resampleAlg, errThreshold )

This should be implemented in qlparser (oql.yy, qtproject.cc).

[Dimitar Misev]

How should the signature of project() look like, what parameters does it have in this case?

[Bang Pham Huu]

It can be like this:

project( mddExpr, boundsIn, crsIn, crsOut, geoAxesResolutions )

with geoAxesResolutions: a string pair of 2 values, e.g: "20.3434, 35.324234"

[Peter Baumann]

if we know we always have a fixed number of two parameters why not have 2 float numbers:

project( mddExpr, boundsIn, crsIn, crsOut, axisResolution1, axisResolution2 )

[Bang Pham Huu]

It should be as one parameter by convention as:

boundsIn - geographic bounding box given as a string of comma-separated
floating-point values of the format: "xmin, ymin, xmax, ymax".

[Dimitar Misev]

I'm still not sure why the boundsIn was designed as a string.. wouldn't take it as a model.

Two float parameters sounds good, similar to widthOut and heightOut.

[Bang Pham Huu]

Just an opinion: I prefer to group related values as 1 parameter (e.g: boundsIn) as it is getting harder when you have too many parameters to put in this project() operator.

[Peter Baumann]

indeed, it's a bad habit and error prone to establish micro syntax. In case of explicit typing the compiler does checks for us, makes it safer.

[Peter Baumann]

Replying to pbaumann:

indeed, it's a bad habit and error prone to establish micro syntax. In case of explicit typing the compiler does checks for us, makes it safer.

I understand your concern, and we should indeed see that we will not have 20 or more parameters at some time. But I see that we are careful when adding, so let's continue being hesitatnt with adding parameters.

[Dimitar Misev]

The problem is that project developed quite a few variants with many parameters; just look at the number of options that gdalwarp has: ​https://gdal.org/programs/gdalwarp.html

It's becoming kind of similar like the format parameters of encode/decode, I'm inclined to think it will benefit from a similar treatment (key/value pair syntax should be enough).

[Peter Baumann]

indeed, saw that now when looking up project() documentation. However, we have started using separate parameters, we should not break that within a given function.

Complication: optional parameters are somewhat involved (such as leaving out parameters earlier in the list than a desired parameter).