You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should probably document at some point in which use cases GeoPackage is a good choice and when another encoding should be used.
Some work has been done already, see the nice overviews in slides 7-9 in [1]. The arguments should be expanded though, e.g. why exactly is GeoPackage not suitable for "Validation/Quality Assurance".
The Dutch government also has some advice on GeoPackage [2]. The main use case is that "GeoPackage must be used when the government offers download of geographic information to third parties", and in [2] are some advantages and disadvantages of GML and GeoPackage described (in Dutch).
If you know other presentations, reports, etc. that can shed light on this issue, please add a reference to them here.
OpenTNF (see www.opentnf.org) is an open specification for interoperability and exchange of data on transport networks. OpenTNF is well suited for exchange of data about transport networks according to INSPIRE. The specification has borrowed model concepts and terms from the Generic network model in “INSPIRE Generic Conceptual Model, Version 3.1” [INSPIRE GCM] and “INSPIRE Data Specification on Transport Networks” [INSPIRE DS TN].
We have chosen OGC GeoPackage and SQLite for implementation instead of e.g. XML/GML mainly for these reasons:
Ability to exchange of potentially large amounts of transport network data in an efficient and standardized way
OGC GeoPackage and SQLite are open, free and allow for a single file for storage and exchange.
SQLite does not imply any limitations in dataset size (at least not in practice) which makes it suitable for very large datasets.
The "Validation/Quality Assurance" issue is important for us and in our implementation, we use, among other things, definitions and mechanisms found in OpenTNF model for data catalogue to validate input data.
We should probably document at some point in which use cases GeoPackage is a good choice and when another encoding should be used.
Some work has been done already, see the nice overviews in slides 7-9 in [1]. The arguments should be expanded though, e.g. why exactly is GeoPackage not suitable for "Validation/Quality Assurance".
The Dutch government also has some advice on GeoPackage [2]. The main use case is that "GeoPackage must be used when the government offers download of geographic information to third parties", and in [2] are some advantages and disadvantages of GML and GeoPackage described (in Dutch).
If you know other presentations, reports, etc. that can shed light on this issue, please add a reference to them here.
[1] REITZ, Thorsten. Alternative Encodings, Alternative APIs, Alternative Models. INSPIRE conference 2020. 8 June 2020. Available from: https://inspire.ec.europa.eu/sites/default/files/thorsten_reitz_-_alternative_encodings_alternative_apis_alternative_models.pdf
[2] https://www.forumstandaardisatie.nl/sites/default/files/Downloads/Bijlagen%20OS/Geo-Standaarden/Forumadvies-GeoPackage.pdf
The text was updated successfully, but these errors were encountered: