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

Prime meridian inconsistency: Copenhagen #4030

Open
mwtoews opened this issue Feb 2, 2024 · 3 comments
Open

Prime meridian inconsistency: Copenhagen #4030

mwtoews opened this issue Feb 2, 2024 · 3 comments
Labels

Comments

@mwtoews
Copy link
Member

mwtoews commented Feb 2, 2024

Copenhagen (EPSG:1026) is defined as 12° 34' 39.9" E, which is different to PROJ's 12d34'40.35"E with a difference of 0.45" or approximately 7.864 m.

This was added to PROJ with #721 (@busstoptaktik). This was followed with a change by IOGP on 10 May 2023, also by @busstoptaktik, but it's not clear if the meridian value was changed.

Is to worth changing or adding meridians for PROJ?

@busstoptaktik
Copy link
Member

I'll have to investigate this further - my memory, but not my reading, tells me that I wrote a very long explanatory commit message telling about both the difference between the old and the new Copenhagen Observatory (in principle built on the same meridian, to continue observations consistently), the new about 1 km due north of the old, to move it out of the light pollution of the sprawling 19th century Danish capital (today the "new" observatory is very much in the city center).

The difference may be due to the 2 observatories actually differing in longitude, or it may be due to different observations in different systems (e.g. System GS, using the Andræ ellipsoid, f=1/300, and System GI, using the international (Hayford) ellipsoid, f=1/297. But (see below) it may also be due to totally prosaic, empirical, and more current reasons...

I believe in principle, the longitudes in System GS were referred to the old observatory (Rundetårn/Runde Taarn "The Round Tower"). In my lab notes from when working out the new transformations, I have this to tell the eternity:

Legacy Danish systems often reckoned longitude from the meridian of the old
Copenhagen Observatory "Rundetårn" (active 1641–1861) [Borre, 2014].

From a poster [GAII, u.å], originally compiled for use in the department for
operational geodesy (G.A.II - "Geodætisk Afdeling II") of the Danish Geodetic
Institute (1928-1989), we know that the offset used to transform to a Greenwich
based longitude was conventionally taken to be
               𝜆 = 12°34'39.9"  ≈  12.57775°E
The conventional latitude was taken to be:
               𝜑 = 55°40'52.3"  ≈  55.68119(444...)°N

[Borre, 2014]
    Kai Borre: Fundamental triangulation networks in Denmark
    Journal of Geodetic Science, vol. 2014, no. 4, pp. 74–-86
[GAII, u.å] Unpublished poster

(where "u.å." is "uden årstal", i.e. "undated" - huge thanks to @tomasmediciportfolio for deciphering and reproducing the vanishing, century-old handwriting on the poster)

It dawns upon me that I may have entered the 12d34'40.35"E into datums.cpp after a conversation with the Icelandic geodetic authority, Landmælingar Íslands (Iceland was under the Danish crown until 1943, so old Icelandic geodetic systems are referred to the Copenhagen prime meridian), so this may simply be the value empirically fitting best in Iceland.

@mwtoews
Copy link
Member Author

mwtoews commented Feb 8, 2024

My thought for now is to "freeze" the initial value (#4042).

@rouault should the EPSG value be added to primeMeridiansDMS?

@rouault
Copy link
Member

rouault commented Feb 8, 2024

should the EPSG value be added to primeMeridiansDMS?

That piece of code is mostly to deal with past WKT output of epsg.org which has probably not percolated much, or for WKT1. I don't feel personally concerned enough by the Copenhagen prime meridian oddity to think more about that, but if you feel about doing it, the floor is yours :-)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants