Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Epoch limitation in GeoPackage WKT Extension #686

Open
jamesresslernga opened this issue Aug 7, 2024 · 1 comment
Open

Epoch limitation in GeoPackage WKT Extension #686

jamesresslernga opened this issue Aug 7, 2024 · 1 comment

Comments

@jamesresslernga
Copy link

Supporting the use of Epoch in GeoPackages for the DGIWG GeoPackage profile (to be edition 1.1), related to issue #675, found a limitation that could be addressed by the SWG.

Because the gpkg_spatial_ref_sys has a single row for each srs_id (primary key) in a GeoPackage, the definition of Epoch for a GeoPackage is limited to one Epoch date per CRS. Without using multiple srs_id values, multiple epoch dates for gridded data with the same srs_id must be stored in distinct GeoPackage files.

How would uses embed 2 different elevation tile matrix sets with the same CRS that were collected at two different time? Could be necessary it the difference is significant number of years.

@rouault
Copy link
Contributor

rouault commented Aug 7, 2024

Because the gpkg_spatial_ref_sys has a single row for each srs_id (primary key) in a GeoPackage, the definition of Epoch for a GeoPackage is limited to one Epoch date per CRS

Just create one entry per (CRS, epoch) tuple that will have its own srs_id. Similarly to what was discussed in #676 (comment) and #676 (comment)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants