Add pj_find_file() function to retrieve the full filename of a proj resource file.

[rouault]

Will help GDAL finding where +nadgrids=... or +geoidgrids=... resouces are located
to be able to directly open them.

Cf 25066cf#commitcomment-21347676

[kbevers]

So you want find to find the location of the grid files with PROJ.4, so you can transform the raster cell values directly with GDAL. Surely you can use the PROJ.4 API to do the offset? This way GDAL doesn't need to know where grids are located. Is it a speed thing?

[rouault]

Surely you can use the PROJ.4 API to do the offset? This way GDAL doesn't need to know where grids are located. Is it a speed thing?

Yes, it is likely more efficient to get the grid raster directly rather than query each point of it through the proj API (actually I offer in GDAL a low level API that use GDAL datasets directly as shift grids, and the use of proj.4 strings to find those grids is a higher level conveniency) And I can potentially choose a different resampling method than bilinear, etc..

[kbevers]

Yes, it is likely more efficient to get the grid raster directly rather than query each point of it through the proj API (actually I offer in GDAL a low level API that use GDAL datasets directly as shift grids, and the use of proj.4 strings to find those grids is a higher level conveniency)

Okay, I understand. Just out of interest, do you only use 2D-transformations i GDAL? Or is 3D-transformations possible as well (even though in many cases they won't make sense)?

[rouault]

do you only use 2D-transformations i GDAL? Or is 3D-transformations possible as well (even though in many cases they won't make sense)?

It depends where. There is a coordinate transformation API, that is mostly a wrapper over pj_transform, that offers 2D or 3D transforms. Here, in the raster warping engine, traditionally we just use the 2D-transformation. As I didn't want to mess in that engine (since that engine doesn't necessarily reproject the coordinate of all points of the raster but does linear approximation to speed-up things), I do the vertical shift step as a preliminary step by using the 2D raster warping service to reproject the vertical shift grid to the extent and resolution of the DEM, and add or substract the 2 datasets. The resulting raster can then be warped to its final SRS using again the 2D raster warping service. Hum, not too confusing ?

[kbevers]

Hum, not too confusing

Not at all. It is sort of the same concept as the transformation pipelines i PROJ.4. Which why I asked. I think GDAL could benefit from some of those new features when they are more mature. With the vgridshift driver that I have proposed you could do essentially the same thing as you are doing in your GDAL gridshift-code. Here it would just be a very simple proj-pipeline and some calls to pj_trans. There is still the issue of speed though. I don't think it would be too bad, but I also don't know your requirements in that regard so I can't really comment on that.

[rouault]

Anyway, do you think the pj_find_file() approach is reasonable ? This gives some "transparency" to users on which files are used.

[kbevers]

Anyway, do you think the pj_find_file() approach is reasonable ? This gives some "transparency" to users on which files are used.

Yes. I think transparency is the main selling point, but making things easier for GDAL is also nice :-)

Could you put in a few lines that document the function? Most of the inputs are self-explanatory, but the name argument could possibly be confusing.

[rouault]

Added Doxygen doc

[kbevers]

Thanks. Feel free to merge when you're happy with the code.