Fix spelling of Potsdam datum

[dg0yt]

No description provided.

[dg0yt]

This is required to fix existing PROJ specs for German Gauß-Krüger with +datum=potsdam. Otherwise PROJ just reports proj_create: unknown datum potsdam.

Using +datum=postdam doesn't work either, due to an "unknown elliptical parameter". So I don't see how I could work around this bug from the application side.

[rouault]

we'll apply it after 6.2.0 release, unless @kbevers sees that as a RC blocker ?
You can probably workaround by replacing +datum=potsdam by +ellps=bessel +nadgrids=@BETA2007.gsb since that's actually what the datum is expanded into

[dg0yt]

You can probably workaround by replacing +datum=potsdam by +ellps=bessel +nadgrids=@BETA2007.gsb since that's actually what the datum is expanded into

Thanks, I will try that later.

I'm under the impression that some API use cases are not covered well by unit tests. I came to this bug with the new API because with the old API, we face an issue with +init=epsg:2056 (CH1903+).

[dg0yt]

You can probably workaround by replacing +datum=potsdam by +ellps=bessel +nadgrids=@BETA2007.gsb since that's actually what the datum is expanded into

👍 Works for me.

[dg0yt]

You can probably workaround by replacing +datum=potsdam by +ellps=bessel +nadgrids=@BETA2007.gsb since that's actually what the datum is expanded into

+1 Works for me.

I discovered that this "works for me" only on desktop systems, not in our Android build. In Android, I have a shift which is eqivalent to not using "+datum=potsdam" or "+ellps=bessel +nadgrids=@BETA2007.gsb".

The only difference in our Android build is the use of a proj_context_set_file_finder function which provides the files such as proj.db and BETA2007.gsb. This function is known to work. Now here, it is called twice from different call stacks, once for "@BETA2007.gsb" and once for "BETA2007.gsb". The second call is successfull. I assume this identical to desktop behaviour, but still I observe the error.

I wonder if there might be another lookup of "BETA2007.gsb" which fails to use the file finder function. If so, it may affect other uses of +nadgrids, and thus not only this obsolete workaround.

I may be able to create a "Minimal, Complete and Verifiable Example" but it will be quite harde to create and use due to the particularities of Android in this interaction of code and resource files. So I hope this description could already ring a bell.
And I can move this report to an explicit issue.

[dg0yt]

Ignore my last comment. I found the issue in my proj_context_set_file_finder function. However, the documentation could be improved regarding the lifetime of the strings returned by that function.

[kbevers]

However, the documentation could be improved regarding the lifetime of the strings returned by that function.

Feel free to suggest an update you find fitting.