The way that IGNF is using in the projection codes does not quite match the GeoPackage standard. The standard has been written with EPSG codes in mind, and even the authors of the standard have been thinking that GPKG should support also other authorities than EPSG, they obviously could not guess what IGNF is going to do.
Have a look at the structure of the gpkg_spatial_ref_sys
table of GeoPackage.
CREATE TABLE gpkg_spatial_ref_sys (
srs_name TEXT NOT NULL,
srs_id INTEGER NOT NULL PRIMARY KEY,
organization TEXT NOT NULL,
organization_coordsys_id INTEGER NOT NULL,
definition TEXT NOT NULL,
description TEXT
);
Now see the definition of this IGNF CRS
GEOGCRS["Lambert Nord de Guerre grades Paris",
DATUM["Nord de Guerre (Paris)",
ELLIPSOID["Plessis 1817",6376523,308.64,
LENGTHUNIT["metre",1]]],
PRIMEM["Paris",2.5969213,
ANGLEUNIT["grad",0.0157079632679489]],
CS[ellipsoidal,2],
AXIS["geodetic longitude (Lon)",east,
ORDER[1],
ANGLEUNIT["grad",0.0157079632679489]],
AXIS["geodetic latitude (Lat)",north,
ORDER[2],
ANGLEUNIT["grad",0.0157079632679489]],
USAGE[
SCOPE["LOCALE, HISTORIQUE"],
AREA["World."],
BBOX[-90,-180,90,180]],
ID["IGNF","LNGPGG"]]
Unfortunately it is impossible to store ID "IGNF:LNPGG"
into gpkg_spatial_ref_sys because the organization_coorsys_id LNPGG
is a string, not an integer. What QGIS does is to save a row with this information into gpkg_spatial_ref_sys:
srs_name: Lambert Nord de Guerre grades Paris
srs_id: 100000
organization: NONE
organization_coordsys_id: 100000
definition: "GEOGCS[""Lambert Nord de Guerre grades Paris"",DATUM[""Nord_de_Guerre_Paris"",SPHEROID[""Plessis 1817"",6376523,308.64,AUTHORITY[""EPSG"",""7027""]],AUTHORITY[""EPSG"",""6902""]],PRIMEM[""Paris"",2.33722917,AUTHORITY[""EPSG"",""8903""]],UNIT[""grad"",0.0157079632679489,AUTHORITY[""EPSG"",""9105""]],AXIS[""Longitude"",EAST],AXIS[""Latitude"",NORTH],AUTHORITY[""IGNF"",""SYSLNG""]]",
description: NULL
QGIS generates code 100000
and uses that both as srs_id
and organization_coordsys_id
. The first usage is OK because srs_id
can be whatever integer in GeoPackage, is just needs to be unique in the table. Number 100000 as organization_coordsys_id
is a fake value, but something like that must be done. The value must not be null, it must be an integer, and the real ID LNGPGG
cannot be used.
I guess that most GeoPackage programs reads the CRS from organization+organization_coordsys_id. It works fine with EPSG codes like EPSG:4326
but in this case the combination is NULL:100000
and unusable. What should work is to read the denifinition string and interpret it. Even the name of the CRS should work.
I do not know how ArcMap tries to find the CRS from this GeoPackage. Maybe you must define the CRS manually and tell ArcMap that the data are in IGNF:LNGPGG
if ArcMap supports it. Otherwise convert the data with QGIS into some suitable EPSG CRS and save the dataset into a new GeoPackage. Also some ESRI CRS should work because ESRI is using integer IDs.