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

Conversation

@dg0yt
Copy link
Contributor

dg0yt commented Aug 30, 2019

No description provided.

@dg0yt

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Contributor Author

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

This comment has been minimized.

Copy link
Contributor Author

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
4 checks passed
FreeBSD Task Summary
Details
Travis CI - Pull Request Build Passed
Details
continuous-integration/appveyor/pr AppVeyor build succeeded
Details
coverage/coveralls Coverage remained the same at 85.904%
Details
@kbevers kbevers added the backport 6.2 label Sep 1, 2019
dg0yt added a commit to OpenOrienteering/mapper that referenced this pull request 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 pull request Oct 20, 2019
Cf. OSGeo/PROJ#1573, expected to be fixed
in PROJ 6.2.1.
Resolves GH-1383 (OSM on GK map).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
3 participants
You can’t perform that action at this time.