Database: update to EPSG v12.049

[rouault]

No description provided.

[jjimenezshaw]

I see that despite the new bunch of members of ETRS89, no test had to be changed. Is that good or bad? I know you changed before it so WKTs are be more flexible related to the members of datum ensembles.

I noticed some reordering (without apparent changes) of entries that make reviewing more complicated. Like in the alias_name.sql or helmert_transformation.sql. How are those files ordered?

[rouault]

Is that good or bad?

I was surprised too but I guess we have been careful writing the test to not being dependent on the exact content of the ensemble

I know you changed before it so WKTs are be more flexible related to the members of datum ensembles.

I made a change some time ago to accept a WKT where the members of the ensemble would be omitted, but the writing side write them all. ETRS89 is now super lengthy:

GEOGCRS["ETRS89",
    ENSEMBLE["European Terrestrial Reference System 1989 ensemble",
        MEMBER["European Terrestrial Reference Frame 1989"],
        MEMBER["European Terrestrial Reference Frame 1990"],
        MEMBER["European Terrestrial Reference Frame 1991"],
        MEMBER["European Terrestrial Reference Frame 1992"],
        MEMBER["European Terrestrial Reference Frame 1993"],
        MEMBER["European Terrestrial Reference Frame 1994"],
        MEMBER["European Terrestrial Reference Frame 1996"],
        MEMBER["European Terrestrial Reference Frame 1997"],
        MEMBER["European Terrestrial Reference Frame 2000"],
        MEMBER["European Terrestrial Reference Frame 2005"],
        MEMBER["European Terrestrial Reference Frame 2014"],
        MEMBER["European Terrestrial Reference Frame 2020"],
        MEMBER["ETRS89-DNK"],
        MEMBER["Estonia 1997"],
        MEMBER["Albanian Geodetic Reference Frame 2010"],
        MEMBER["ETRS89-ALB [CORS]"],
        MEMBER["ETRS89-AUT [2002]"],
        MEMBER["Belgian Reference Frame 2002"],
        MEMBER["Belgian Reference Frame 2011"],
        MEMBER["BH_ETRS89"],
        MEMBER["Bulgaria Geodetic System 2005"],
        MEMBER["Croatian Terrestrial Reference System 1996"],
        MEMBER["AGRS2010 (ETRF2000)"],
        MEMBER["CROPOS"],
        MEMBER["ETRF2000 Poland"],
        MEMBER["ETRS89/DREF91 Realization 2016"],
        MEMBER["ETRS89/DREF91 Realization 2025"],
        MEMBER["ETRS89-CZE [2007]"],
        MEMBER["ETRS89-ESP [REGENTE]"],
        MEMBER["ETRS89-ESP [ERGNSS]"],
        MEMBER["ETRS89-FRO [2008]"],
        MEMBER["ETRS89-GRC [HTRS07]"],
        MEMBER["ETRS89-HUN [ETRF2000]"],
        MEMBER["ETRS89-IRE [ETRF2000]"],
        MEMBER["ETRS89-MKD [EUREF-MAK2010]"],
        MEMBER["ETRS89-NOR [EUREF89]"],
        MEMBER["ETRS89-PRT [1995]"],
        MEMBER["ETRS89-ROU [ETRF2000]"],
        MEMBER["ETRS89-SVK [SKTRF09]"],
        MEMBER["ETRS89-SVK [SKTRF2022]"],
        MEMBER["EUREF-FIN"],
        MEMBER["Istituto Geografico Militaire 1995"],
        MEMBER["Kosovo Reference System 2001"],
        MEMBER["Latvian geodetic coordinate system 1992"],
        MEMBER["Latvian coordinate system 2020"],
        MEMBER["Lithuania 1994 (ETRS89)"],
        MEMBER["MOLDREF99"],
        MEMBER["OSNet v2009"],
        MEMBER["Reseau Geodesique Francais 1993 v1"],
        MEMBER["Reseau Geodesique Francais 1993 v2"],
        MEMBER["Reseau Geodesique Francais 1993 v2b"],
        MEMBER["Rete Dinamica Nazionale 2008"],
        MEMBER["Serbian Reference Network 1998"],
        MEMBER["Serbian Spatial Reference System 2000"],
        MEMBER["Slovenia Geodetic Datum 1996"],
        MEMBER["SWEREF 99"],
        MEMBER["Swiss Terrestrial Reference Frame 1995"],
        ELLIPSOID["GRS 1980",6378137,298.257222101,
            LENGTHUNIT["metre",1]],
        ENSEMBLEACCURACY[0.1]],
    PRIMEM["Greenwich",0,
        ANGLEUNIT["degree",0.0174532925199433]],
    CS[ellipsoidal,2],
        AXIS["geodetic latitude (Lat)",north,
            ORDER[1],
            ANGLEUNIT["degree",0.0174532925199433]],
        AXIS["geodetic longitude (Lon)",east,
            ORDER[2],
            ANGLEUNIT["degree",0.0174532925199433]],
    USAGE[
        SCOPE["Spatial referencing."],
        AREA["Europe - onshore and offshore: Albania; Andorra; Austria; Belgium; Bosnia and Herzegovina; Bulgaria; Croatia; Czechia; Denmark; Estonia; Faroe Islands; Finland; France; Germany; Gibraltar; Greece; Hungary; Ireland; Italy; Kosovo; Latvia; Liechtenstein; Lithuania; Luxembourg; Malta; Moldova; Monaco; Montenegro; Netherlands; North Macedonia; Norway including Svalbard and Jan Mayen; Poland; Portugal - mainland; Romania; San Marino; Serbia; Slovakia; Slovenia; Spain - mainland and Balearic islands; Sweden; Switzerland; United Kingdom (UK) including Channel Islands and Isle of Man; Vatican City State."],
        BBOX[33.26,-16.1,84.73,38.01]],
    ID["EPSG",4258],
    REMARK["Has been realized through ETRF89, ETRF90, ETRF91, ETRF92, ETRF93, ETRF94, ETRF96, ETRF97, ETRF2000, ETRF2005 and ETRF2014. This 'ensemble' covers any or all of these realizations without distinction."]]

I noticed some reordering (without apparent changes) of entries that make reviewing more complicated. Like in the alias_name.sql or helmert_transformation.sql. How are those files ordered?

I suspect mostly from the order from the EPSG .sql dump. Although we insert them in a temporary sqlite db, so this could potentially depend on the SQLite version when we SELECT without ORDER (although I believe the current implementation must return in the same order as the insertion one)

[rhuijben]

Ordering in sqlite is undefined unless you use an explicit order. There is an easy pragma (PRAGMA reverse_unordered_selects;) to see where you depend on unspecified ordering, as that explicitly makes everything with undefined order return in the opposite order. (This only breaks if your tests have the same bug ;-))

Typically it will just use the cheapest way, but that really depends on what indexes are used after optimizing the query. But that may change with versions.