Re: [gdal-dev] Bug reading a byn file for Canadian geoid model?
I started a branch to fix it. Looks like there enough info in the byn header. On Wed, 15 Jul 2026, 20:00 Even Rouault, wrote: > Javier, > > I'd assume that code that assigns datums to have only been valid for the > particular grids it was developped for. You'd better ignore any CRS > information reported by the driver and override them from the > documentation of the grid you're interested in > > Even > > Le 09/07/2026 à 17:20, Javier Jimenez Shaw via gdal-dev a écrit : > > Hi > > > > I am trying to read this file, in theory based in ITRF > > > https://webapp.csrs-scrs.nrcan-rncan.gc.ca/geod/process/download-helper.php?file_id=GSD95 > > (there is another one based in NAD83xxx) > > > > However in with gdalinfo I see this: > > "Warning 1: CRS EPSG:4140 is deprecated. Its non-deprecated > > replacement EPSG:4617 will be used instead. To use the original CRS, > > set the OSR_USE_NON_DEPRECATED configuration option to NO." > > > > EPSG:4140 https://spatialreference.org/ref/epsg/4140/ > > is NAD83(CSRS98), that is not ITRF, as far as I know. > > > > However in byndataset.h there is this line: > > > > constexpr int BYN_DATUM_0 = 4140; /* ITRF2008 (GRS80 based WGS84) */ > > > > https://github.com/OSGeo/gdal/blob/master/frmts/raw/byndataset.h#L168 > > > > Are we parsing the header wrongly? > > > > There is some documentation in > > > https://webapp.csrs-scrs.nrcan-rncan.gc.ca/geod/tools-outils/sample_doc_files/NRCan_Geoid_GridFormat_EN_2023.pdf > > I think what I say above applies to the field 16, Datum. > > > > Thanks > > Javier > > > > ___ > > gdal-dev mailing list > > [email protected] > > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > -- > http://www.spatialys.com > My software is free, but my time generally not. > LLMs contribute to global warming and brain rot. > > ___ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bug reading a byn file for Canadian geoid model?
Javier, I'd assume that code that assigns datums to have only been valid for the particular grids it was developped for. You'd better ignore any CRS information reported by the driver and override them from the documentation of the grid you're interested in Even Le 09/07/2026 à 17:20, Javier Jimenez Shaw via gdal-dev a écrit : Hi I am trying to read this file, in theory based in ITRF https://webapp.csrs-scrs.nrcan-rncan.gc.ca/geod/process/download-helper.php?file_id=GSD95 (there is another one based in NAD83xxx) However in with gdalinfo I see this: "Warning 1: CRS EPSG:4140 is deprecated. Its non-deprecated replacement EPSG:4617 will be used instead. To use the original CRS, set the OSR_USE_NON_DEPRECATED configuration option to NO." EPSG:4140 https://spatialreference.org/ref/epsg/4140/ is NAD83(CSRS98), that is not ITRF, as far as I know. However in byndataset.h there is this line: constexpr int BYN_DATUM_0 = 4140; /* ITRF2008 (GRS80 based WGS84) */ https://github.com/OSGeo/gdal/blob/master/frmts/raw/byndataset.h#L168 Are we parsing the header wrongly? There is some documentation in https://webapp.csrs-scrs.nrcan-rncan.gc.ca/geod/tools-outils/sample_doc_files/NRCan_Geoid_GridFormat_EN_2023.pdf I think what I say above applies to the field 16, Datum. Thanks Javier ___ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev -- http://www.spatialys.com My software is free, but my time generally not. LLMs contribute to global warming and brain rot. ___ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
Re: [gdal-dev] Bug reading a byn file for Canadian geoid model?
Javier Jimenez Shaw via gdal-dev writes: > I am trying to read this file, in theory based in ITRF > https://webapp.csrs-scrs.nrcan-rncan.gc.ca/geod/process/download-helper.php?file_id=GSD95 > (there is another one based in NAD83xxx) > > However in with gdalinfo I see this: > "Warning 1: CRS EPSG:4140 is deprecated. Its non-deprecated replacement > EPSG:4617 will be used instead. To use the original CRS, set the > OSR_USE_NON_DEPRECATED configuration option to NO." > > EPSG:4140 https://spatialreference.org/ref/epsg/4140/ is NAD83(CSRS98), > that is not ITRF, as far as I know. It is definitely not ITRF. Canada and the US have both had multiple realizations of NAD83 after jointly adopting NAD83(1986). CSRS98 is the second Canadian realization after the original, and I think is also called CSRSv2 https://natural-resources.canada.ca/science-data/science-research/geomatics/geodetic-reference-systems/spatial-reference-system-updates It is defined as a transform from ITRF96, but that's not equal to, but surely an euler pole rotation. My guess is that this is just the process of having a datum, then a revision, then adopting the view that there will be many revisions, and viewing it as a system, which was perhaps not entirely foreseen from the start, and then moving from ad hoc names to a vN scheme that emphasizes and communicates the minor revision nature. As for deprecation: https://spatialreference.org/ref/epsg/4140/ https://spatialreference.org/ref/epsg/4617/ https://spatialreference.org/ref/epsg/4955/ this looks like a right mess of ensemble thinking, from taking the CSRS definitions -- which are surely geodetically rigorous -- and forcing them into EPSG. 4955 is not showing as an ensemble or as a system in EPSG. It seems Canada relabeled the base NAD83(CSRS) as a system and then has realizations of that system. It is a problem in the NAD83 world that really there is an ensemble, at last in practice, but the formal language doesn't talk about it that way, and doesn't really emphasize the system aspect. It's not so much a problem in the NAD83 world as much as a problem in talking about the NAD83 world in the EPSG language. > However in byndataset.h there is this line: > > constexpr int BYN_DATUM_0 = 4140; /* ITRF2008 (GRS80 based WGS84) */ > > https://github.com/OSGeo/gdal/blob/master/frmts/raw/byndataset.h#L168 That line is very odd, but I wonder if the comment is just off, and the "deprecated/replacing" is straight from EPSG and not from that file. What if you change that to 994140 - do you still get the warning? > Are we parsing the header wrongly? It does not seem odd to me that what is likely a geoid model from/for 1995 is expressed in CSRS98. ___ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
[gdal-dev] Bug reading a byn file for Canadian geoid model?
Hi I am trying to read this file, in theory based in ITRF https://webapp.csrs-scrs.nrcan-rncan.gc.ca/geod/process/download-helper.php?file_id=GSD95 (there is another one based in NAD83xxx) However in with gdalinfo I see this: "Warning 1: CRS EPSG:4140 is deprecated. Its non-deprecated replacement EPSG:4617 will be used instead. To use the original CRS, set the OSR_USE_NON_DEPRECATED configuration option to NO." EPSG:4140 https://spatialreference.org/ref/epsg/4140/ is NAD83(CSRS98), that is not ITRF, as far as I know. However in byndataset.h there is this line: constexpr int BYN_DATUM_0 = 4140; /* ITRF2008 (GRS80 based WGS84) */ https://github.com/OSGeo/gdal/blob/master/frmts/raw/byndataset.h#L168 Are we parsing the header wrongly? There is some documentation in https://webapp.csrs-scrs.nrcan-rncan.gc.ca/geod/tools-outils/sample_doc_files/NRCan_Geoid_GridFormat_EN_2023.pdf I think what I say above applies to the field 16, Datum. Thanks Javier ___ gdal-dev mailing list [email protected] https://lists.osgeo.org/mailman/listinfo/gdal-dev
