You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@sis.apache.org by Martin Desruisseaux <ma...@geomatys.com> on 2024/07/24 22:10:53 UTC
Is support of older EPSG database needed?
Hello all
Apache SIS is capable to connect directly to an EPSG database version
9.x without the need to convert the database to some project-specific
schema. It allows, for example, to connect to many EPSG databases for
different versions. Therefore, authority codes like "EPSG:9.7:4326" and
"EPSG:9.9:4326" (for example) will use the versions 9.7 and 9.9
respectively of the EPSG database for the same 4326 code, if those
versions are available on the user's machine.
We are upgrading the EPSG database from version 9.9.1 to 11.012. But
there is some changes in the EPSG schema introduced in version 10 which
need to be reflected by changes in the Java code. Consequently, it would
be a little bit difficult to support both versions 9.x and versions 11.x
of the EPSG database. Is there any objection to drop support for
versions 9.x of the EPSG database? Note: if support for versions 9.x was
needed, it could be done by creating SQL views. But it would require
some work.
Martin
Re: Is support of older EPSG database needed?
Posted by Alexis Manin <al...@geomatys.com>.
Ok.
I've checked the behaviour of Python library rasterio when we feed it a WKT
2 using a datum ensemble, and it looks like it's fine.
So no objection on my side.
Tested script, for reference:
from rasterio.crs import CRS, WktVersion
>
> ogc_crs84_wkt2 = """
> GEOGCRS["WGS 84 (CRS84)",
> ENSEMBLE["World Geodetic System 1984 ensemble",
> MEMBER["World Geodetic System 1984 (Transit)"],
> MEMBER["World Geodetic System 1984 (G730)"],
> MEMBER["World Geodetic System 1984 (G873)"],
> MEMBER["World Geodetic System 1984 (G1150)"],
> MEMBER["World Geodetic System 1984 (G1674)"],
> MEMBER["World Geodetic System 1984 (G1762)"],
> MEMBER["World Geodetic System 1984 (G2139)"],
> ELLIPSOID["WGS 84",6378137,298.257223563,
> LENGTHUNIT["metre",1]],
> ENSEMBLEACCURACY[2.0]],
> PRIMEM["Greenwich",0,
> ANGLEUNIT["degree",0.0174532925199433]],
> CS[ellipsoidal,2],
> AXIS["geodetic longitude (Lon)",east,
> ORDER[1],
> ANGLEUNIT["degree",0.0174532925199433]],
> AXIS["geodetic latitude (Lat)",north,
> ORDER[2],
> ANGLEUNIT["degree",0.0174532925199433]],
> USAGE[
> SCOPE["Not known."],
> AREA["World."],
> BBOX[-180,-90,180,90]],
> ID["OGC","CRS84"]]
> """
>
> decoded_crs = CRS.from_wkt(ogc_crs84_wkt2)
> assert decoded_crs.is_valid
> assert decoded_crs.is_geographic
>
> print(decoded_crs.to_wkt(version=WktVersion.WKT2_2019))
>
>
Regards,
Le jeu. 25 juil. 2024 à 09:49, Martin Desruisseaux <
martin.desruisseaux@geomatys.com> a écrit :
> Le 2024-07-25 à 07 h 50, Alexis Manin a écrit :
> >
> > The only question that comes to mind is: would it affect CRS WKT
> > serialization in any way ? For interoperability with third-party
> > systems, WKT is often used. If the EPSG upgrade do not cause
> > incompatible/breaking changes in this regard, then dropping old EPSG
> > version might be a problem.
> >
> It does in some way. In EPSG:4326, the datum is no longer a datum but a
> datum ensemble. It means that in WKT 2, the DATUM["WGS 84", ...] element
> become ENSEMBLE["WGS 84", more stuff]. The latter did not existed in ISO
> 19162:2015 and requires ISO 19162:2019. Therefore, the WKT become
> unparseable for applications that haven't upgraded to ISO 19162:2019
> yet. It includes Apache SIS itself (the upgrade is in progress, in
> parallel with the EPSG upgrade).
>
> However, the WKT 2 strings that I see circulating in other projects and
> in OGC testbeds are already ISO 19162:2019 strings. I have not seen an
> "old" 19162:2015 string for a long time. So it seems that most of the
> market already moved there.
>
> Martin
>
>
--
Alexis Manin,
Développeur JAVA/JEE.
Geomatys.
Re: Is support of older EPSG database needed?
Posted by Martin Desruisseaux <ma...@geomatys.com>.
Le 2024-07-25 à 07 h 50, Alexis Manin a écrit :
>
> The only question that comes to mind is: would it affect CRS WKT
> serialization in any way ? For interoperability with third-party
> systems, WKT is often used. If the EPSG upgrade do not cause
> incompatible/breaking changes in this regard, then dropping old EPSG
> version might be a problem.
>
It does in some way. In EPSG:4326, the datum is no longer a datum but a
datum ensemble. It means that in WKT 2, the DATUM["WGS 84", ...] element
become ENSEMBLE["WGS 84", more stuff]. The latter did not existed in ISO
19162:2015 and requires ISO 19162:2019. Therefore, the WKT become
unparseable for applications that haven't upgraded to ISO 19162:2019
yet. It includes Apache SIS itself (the upgrade is in progress, in
parallel with the EPSG upgrade).
However, the WKT 2 strings that I see circulating in other projects and
in OGC testbeds are already ISO 19162:2019 strings. I have not seen an
"old" 19162:2015 string for a long time. So it seems that most of the
market already moved there.
Martin
Re: Is support of older EPSG database needed?
Posted by Alexis Manin <al...@gmail.com>.
Hi,
I barely ever see the use of a version in decoded EPSG codes, so I do not
think it would be a problem to drop support for older EPSG versions in this
regard.
The only question that comes to mind is: would it affect CRS WKT
serialization in any way ?
For interoperability with third-party systems, WKT is often used. If the
EPSG upgrade do not cause incompatible/breaking changes in this regard,
then dropping old EPSG version might be a problem.
Otherwise, I do not see any problem on dropping support for EPSG 9.x.
Regards,
Le jeu. 25 juil. 2024 à 00:11, Martin Desruisseaux <
martin.desruisseaux@geomatys.com> a écrit :
> Hello all
>
> Apache SIS is capable to connect directly to an EPSG database version
> 9.x without the need to convert the database to some project-specific
> schema. It allows, for example, to connect to many EPSG databases for
> different versions. Therefore, authority codes like "EPSG:9.7:4326" and
> "EPSG:9.9:4326" (for example) will use the versions 9.7 and 9.9
> respectively of the EPSG database for the same 4326 code, if those
> versions are available on the user's machine.
>
> We are upgrading the EPSG database from version 9.9.1 to 11.012. But
> there is some changes in the EPSG schema introduced in version 10 which
> need to be reflected by changes in the Java code. Consequently, it would
> be a little bit difficult to support both versions 9.x and versions 11.x
> of the EPSG database. Is there any objection to drop support for
> versions 9.x of the EPSG database? Note: if support for versions 9.x was
> needed, it could be done by creating SQL views. But it would require
> some work.
>
> Martin
>
>
>