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

Fix spelling of Potsdam datum #1573

Merged
merged 1 commit into from Sep 1, 2019
Merged

Fix spelling of Potsdam datum #1573

merged 1 commit into from Sep 1, 2019

Conversation

dg0yt
Copy link
Contributor

@dg0yt dg0yt commented Aug 30, 2019

No description provided.

@dg0yt
Copy link
Contributor Author

@dg0yt dg0yt commented Aug 31, 2019

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

@rouault rouault commented Aug 31, 2019

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

@dg0yt dg0yt commented Aug 31, 2019

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

@dg0yt dg0yt commented Aug 31, 2019

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.

@kbevers kbevers added this to the 6.2.1 milestone Sep 1, 2019
@kbevers kbevers merged commit 57ec0c2 into OSGeo:master Sep 1, 2019
4 checks passed
dg0yt added a commit to OpenOrienteering/mapper that referenced this issue Oct 20, 2019
Cf. OSGeo/PROJ#1573, expected to be fixed
in PROJ 6.2.1.
Resolves GH-1383 (OSM on GK map).
dg0yt added a commit to OpenOrienteering/mapper that referenced this issue Oct 20, 2019
Cf. OSGeo/PROJ#1573, expected to be fixed
in PROJ 6.2.1.
Resolves GH-1383 (OSM on GK map).
@dg0yt
Copy link
Contributor Author

@dg0yt dg0yt commented Mar 4, 2020

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

@dg0yt dg0yt commented Mar 5, 2020

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

@kbevers kbevers commented Mar 5, 2020

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.

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.

None yet

3 participants