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

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

Closed
wants to merge 1 commit into from

Conversation

rouault
Copy link
Member

@rouault rouault commented Mar 16, 2017

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

Cf 25066cf#commitcomment-21347676

@kbevers
Copy link
Member

kbevers commented Mar 16, 2017

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
Copy link
Member Author

rouault commented Mar 16, 2017

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..

@rouault rouault force-pushed the pj_find_file branch 2 times, most recently from 92955b9 to 9f16ba8 Compare March 16, 2017 12:31
@kbevers
Copy link
Member

kbevers commented Mar 16, 2017

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
Copy link
Member Author

rouault commented Mar 16, 2017

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
Copy link
Member

kbevers commented Mar 16, 2017

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
Copy link
Member Author

rouault commented Mar 16, 2017

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

@kbevers
Copy link
Member

kbevers commented Mar 16, 2017

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.

…esource file.

Will help GDAL finding where +nadgrids=... or +geoidgrids=... resouces are located
to be able to directly open them.
@rouault
Copy link
Member Author

rouault commented Mar 16, 2017

Added Doxygen doc

@kbevers
Copy link
Member

kbevers commented Mar 16, 2017

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

@rouault rouault closed this Mar 16, 2017
@kbevers kbevers added this to the 4.9.4 milestone Mar 16, 2017
@kbevers kbevers modified the milestones: 5.0.0-b, 5.0.0 Feb 1, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants