Add EPSG:10306 (Latvia LKS-2020) to Library of Coordinate Systems
Add EPSG:10306 (Revision date: 2023-03-01) to the Microstation 2024 library ASAP. EPSG:10306 replaces LKS-92 / Latvia TM (CRS code 3059) by year 2024. It is critical to have it in Microstation 2025. It is already available in ESRI products and QGIS.
To clarify, the Latvia2020.TM coordinate system (EPSG:103306) has been implemented, but we intentionally did not follow the older convention of including the EPSG code in the name. This is because EPSG codes can have multiple definitions, (for example EPSG:5514 and EPSG:27700 have over 5 definitions or more each). The entry should still be discoverable via search.
Regarding the absence of the use of the GSB file with this entry, the datum shift definitions are always specified from a datum to the base WGS84 or coincident. In the Latvia's case, the base datum is ETRF89.
The LKS-2020 datum is coincident with ETRF89 and thus there is no datum transformation implemented for this datum.
The datum LKS-1992 used to be defined as coincident to ETRF89 and therefore no datum transformation is implemented either.
It follows that transformation from LKS-1992 to LKS-2020 is also a null transformation.
In these definitions we are refering to two different realisations of ETRF89 and unfortunately the underlying Open Source CSMAP library does not offer the possibility to define multiple realisations of WGS84, or ETRF89 or similar.
There are two ways to have an LKS1992 datum that applies a non-null transformation when changing coordinates to LKS2020.
Either we change the definition of LKS1992
Or we introduce a new version of LKS1992
In the past we have tried changing a datum definition and it was not a good solution. Older data still needs to be stable and clients wanted to keep the relationship to the former realisation of their base datum.
The second option is the only one that will allow former data to keep the relationship to the previous realisation.
This is what has been implemented:
And a newer definition of EPSG:3056 was introduced based on this Latvia1992/GSB datum (Latvia1992.TM/GSB). The previous definition Latvia1992.TM still exists and remains unchanged but has been moved to the 'Legacy' folder in the geopolitical hierarchy. This insures that former historical data will keep aligned with the previous realisation of ETRF89, for example keeping global imagery such as Google aligned with previous data.
This, unfortunately, implies that clients who want to migrate their data from Latvia1992.TM to Latvia2020.TM using the grid shift files must explicitely do so by correcting the CRS from Latvia1992.TM to Latvia1992.TM/GSB, then reprojecting to Latvia2020.TM
This is the exact same process Australia went through when they introduced GDA2020 to superseed GDA1994 introducing new grid files. To migrate they had to correct to the new GDA94/GSB datum then reproject to GDA2020 effectively applying the grid files.
MS2025.1 is out but instead of adding EPSG:10306 it seems Bentley edited LKS92 to include grid shift but it is of no use as existing files are already in EPSG:3059 and there is no need to change old GCS.
Thank you for your feedback.
To clarify, the Latvia2020.TM coordinate system (EPSG:103306) has been implemented, but we intentionally did not follow the older convention of including the EPSG code in the name. This is because EPSG codes can have multiple definitions, (for example EPSG:5514 and EPSG:27700 have over 5 definitions or more each). The entry should still be discoverable via search.
Regarding the absence of the use of the GSB file with this entry, the datum shift definitions are always specified from a datum to the base WGS84 or coincident. In the Latvia's case, the base datum is ETRF89.
The LKS-2020 datum is coincident with ETRF89 and thus there is no datum transformation implemented for this datum.
The datum LKS-1992 used to be defined as coincident to ETRF89 and therefore no datum transformation is implemented either.
It follows that transformation from LKS-1992 to LKS-2020 is also a null transformation.
In these definitions we are refering to two different realisations of ETRF89 and unfortunately the underlying Open Source CSMAP library does not offer the possibility to define multiple realisations of WGS84, or ETRF89 or similar.
There are two ways to have an LKS1992 datum that applies a non-null transformation when changing coordinates to LKS2020.
Either we change the definition of LKS1992
Or we introduce a new version of LKS1992
In the past we have tried changing a datum definition and it was not a good solution. Older data still needs to be stable and clients wanted to keep the relationship to the former realisation of their base datum.
The second option is the only one that will allow former data to keep the relationship to the previous realisation.
This is what has been implemented:
And a newer definition of EPSG:3056 was introduced based on this Latvia1992/GSB datum (Latvia1992.TM/GSB). The previous definition Latvia1992.TM still exists and remains unchanged but has been moved to the 'Legacy' folder in the geopolitical hierarchy. This insures that former historical data will keep aligned with the previous realisation of ETRF89, for example keeping global imagery such as Google aligned with previous data.
This, unfortunately, implies that clients who want to migrate their data from Latvia1992.TM to Latvia2020.TM using the grid shift files must explicitely do so by correcting the CRS from Latvia1992.TM to Latvia1992.TM/GSB, then reprojecting to Latvia2020.TM
This is the exact same process Australia went through when they introduced GDA2020 to superseed GDA1994 introducing new grid files. To migrate they had to correct to the new GDA94/GSB datum then reproject to GDA2020 effectively applying the grid files.
See https://bentleysystems.service-now.com/community?sys_kb_id=d7a9affc1bf18a90f3fc5287624bcb79&id=kb_article_view&sysparm_rank=1&sysparm_tsqueryId=5cb7981287e83210c0fa43f6cebb3530 for details.
Hope this helps
EPSG:10306 is not shipped. Bentley shipped EPSG:3059+GSB which doesn't exist. What was expected is EPSG:10306+GSB.
MS2025.1 is out but instead of adding EPSG:10306 it seems Bentley edited LKS92 to include grid shift but it is of no use as existing files are already in EPSG:3059 and there is no need to change old GCS.
Transformation grid from EPSG:3059 to EPSG:10306 is now published.
https://www.lgia.gov.lv/lv/zinas/parejas-virsma-uz-lks-2020-ntv2-formata
Custom GCS stopped working in MS2024 - #CS0275500