[PROJ] Advice for debugging network callback implementation

Stephan Hügel urschrei at gmail.com
Mon Jul 13 10:39:23 PDT 2020


I’m currently implementing PROJ's network callback functionality for the proj-rs Rust crate. I’ve got a skeleton of the functionality, but the docs are a little vague on some points, which is making debugging tricky. Specifically, I’ve implemented the four callbacks (open_cbk, close_cbk, get_header_value_cbk, read_range_cbk), and I’ve set up my test as follows:

- chosen EPSG codes that will trigger a download: from EPSG4326, to EPSG:4326+3855
- create new proj context with proj_context_create
- disabled the grid cache
- enabled the network callbacks using set_network_callbacks
- used the context to create a transform between known EPSG codes using proj_create_crs_to_crs
- A call to open_cbk is triggered:

The url is https://cdn.proj.org/us_nga_egm08_25.tif, with a “Range: bytes=0-16384” header.
I can confirm that I get 1639 bytes of content back, along with a response header: “content-range: bytes 0-1638/93581”
I cast the response bytes to a void pointer, and assign it to the buffer that is passed into open_cbk by PROJ.
I assign the headers and a client instance (this is an implementation detail for now) to a struct which I cast to a void pointer and then to a *PROJ_NETWORK_HANDLE, which I return.

PROJ then calls get_header_value_cbk, passing in *PROJ_NETWORK_HANDLE and the header name, to check the value of "content-range”, which is (again, correctly I believe) "bytes 0-16384/80585622”

At this point, I get an error: "failed to load datum shift file”.

I’m now not sure where to proceed next: Is there any special format or structure I should be assigning to the bytes from the GET call before I cast them to a void pointer and put them into the buffer? Is there any way I can verify that I’m getting back what I should? I can certainly manually read the first 16385 bytes from the tif, and compare them to what I get back over the wire.
What is PROJ trying to do as a next step after it checks the header value, as this is the step which is currently failing?

Any advice gratefully received.


-- 
steph




More information about the PROJ mailing list