Replies: 3 comments 2 replies
-
|
This is a much appreciated feature waiting I think, #170 is one example of this. Sqlite aren't viewable in QGIS 3 when the spatialite extension isn't activate. It is readable though within ArcGIS. |
Beta Was this translation helpful? Give feedback.
-
|
At this point, if we use a proper spatial format, location could be saved directly into a point feature rather then a table. |
Beta Was this translation helpful? Give feedback.
-
|
A good point about geopackage is that it is aligned with OGC standards: https://www.geopackage.org/ |
Beta Was this translation helpful? Give feedback.
-
|
https://imathworks.com/gis/gis-using-geopackage-instead-of-spatialite-and-vice-versa/ |
Beta Was this translation helpful? Give feedback.
-
|
I've tested different combination for Geopackages: Geopackage Created in QGIS
Geopackage Created in ArcGIS Pro
Also, the format is supported in the esri sdk: https://developers.arcgis.com/net/uwp/sample-code/read-geopackage/ |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
Currently, we're using an SQLite database. We do have some python script that enables SpatiaLite extension to work, we can then use some point features for location and some more neat process. But then, although SpatiaLite is native to QGIS, the current format isn't editable within ArcGIS Pro in it's current form because the tables/features are missing an ESRI OID field.
We know that Geopackages and SpatiaLite databases are editable within Arc Pro 2.9 if created from within the software. It adds the much needed OID field.
Use of SQLite was found to be more light and faster for our usage on site as opposed to a Spatialite who comes blank with around 6-7 Mb compared to a couple of Ko for sqlite. That was, 5 years ago.
On another side latest format of geopackage (1.3) weights less then 200Ko compared to a blank spatialite database.
More testing is needed.
Beta Was this translation helpful? Give feedback.
All reactions