<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Matthias,</p>
<p>Thank you for listing all the open issues/problem with gpkg that
you know of. It really helps.</p>
<p>If we don't like gpkg as default format - the question is: what
is the alternative?</p>
<p>a) stay with ESRI shapefile (I think noone would like this)<br>
b) work with the SQLite, gpkg/OGC community to fix the gpkg issues
(my preference)<br>
c) use ESRI FGDB format (then we are at the mercy of ESRI)<br>
d) invent something new (risky, if only QGIS uses that,
interoperability would suck)</p>
<p>I would prefer option b) a lot, and if that is not feasible, then
maybe d). d) will also be risky.<br>
</p>
<p>a) would equally suck as the current state of gpkg - I've seen
far too many corrupt shape files, people complaining about
interoperability issues (ArcGIS would show features that had been
deleted in QGIS, ) and I don't need to repeat the list of the
numerous restrictions of ESRI shp format.</p>
<p>Andreas<br>
</p>
<div class="moz-cite-prefix">Am 08.05.20 um 11:30 schrieb Matthias
Kuhn:<br>
</div>
<blockquote type="cite"
cite="mid:4432048f-efef-5d9c-51cc-7a50af2ab443@opengis.ch">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<p>Hi list,</p>
<p>I wondered about the state of GeoPackage. Personally, cince it
has been introduced to qgis and evenmore since it has been
selected as the default format, I have never grown to fully and
completely.</p>
<p>I do not want to trigger a evangelical discussion here. I'd
like to see where we are and what we can reasonably do to have a
default file format which can be recommended with no bad
feelings.<br>
</p>
<p><br>
</p>
<p>Here follow a couple of observations over the years, some of
them properties of the specs I believe:</p>
<p><br>
</p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr">* The fid requirement</span></p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr"> I sometimes want my features to be
identified by uuids or others. They also tend to accumulate if
derived datasets are created (through processing etc). If I
need some pseudo stable primary key there is a rowid builtin
into sqlite, we don't need a second one.<br>
</span></p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr"> Possible mitigation: alter the ogr
implementation. possibly alter the standard (required?)<br>
</span></p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr"></span><span id=":ws.co" class="tL8wMe
EMoHub" style="text-align: left;" dir="ltr"><span id=":ws.co"
class="tL8wMe EMoHub" style="text-align: left;" dir="ltr">*
</span>The modification on r/o open</span></p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr"> Has caused too much pain on git.</span></p>
<p style=" margin-top:0px; margin-bottom:0px; margin-left:0px;
margin-right:0px; -qt-block-indent:0; text-indent:0px;
-qt-user-state:0;"><span id=":ws.co" class="tL8wMe EMoHub"
style="text-align: left;" dir="ltr"> Possible mitigation: a)
switch to journal mode=delete (not an easy option because of </span><a
class="moz-txt-link-freetext"
href="https://issues.qgis.org/issues/15351"
moz-do-not-send="true">https://issues.qgis.org/issues/15351</a>)
b) only switch to wal mode when layers are put into edit mode (I
have strong doubts this is a safe thing to do)<br>
</p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr"></span></p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr"></span><span id=":ws.co" class="tL8wMe
EMoHub" style="text-align: left;" dir="ltr"><span id=":ws.co"
class="tL8wMe EMoHub" style="text-align: left;" dir="ltr">*
</span>The network share freeze</span></p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr"> Our default file should play nicely with
(windows) network shares. It's clear to everyone that we can't
expect concurrent writes. But it should "just work" for
concurrent read by many.</span></p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr"> Possible mitigation: switch to journal
mode=delete for network shares (we are looking into this)<br>
</span></p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr"></span><span id=":ws.co" class="tL8wMe
EMoHub" style="text-align: left;" dir="ltr"><span id=":ws.co"
class="tL8wMe EMoHub" style="text-align: left;" dir="ltr">*
</span>The wal file appearing next to the file</span></p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr"> It is confusing to newcomers and looks
almost like a sidecar file. I would care less if it was put
into some system cache folder instead of just into my data
folder. Or at least if it was a hidden file.<br>
</span></p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr"> Possible mitigation: switch to journal
mode=delete (</span><span id=":ws.co" class="tL8wMe EMoHub"
style="text-align: left;" dir="ltr"><span id=":ws.co"
class="tL8wMe EMoHub" style="text-align: left;" dir="ltr">not
an easy option because of </span><a
class="moz-txt-link-freetext"
href="https://issues.qgis.org/issues/15351"
moz-do-not-send="true">https://issues.qgis.org/issues/15351</a>)</span></p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr"></span><span id=":ws.co" class="tL8wMe
EMoHub" style="text-align: left;" dir="ltr"><span id=":ws.co"
class="tL8wMe EMoHub" style="text-align: left;" dir="ltr">*
</span>The couple of corrupted files I have received over the
years which could only be repaired by a command line "dump
contents as sql and execute into new file"</span></p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr"> I have not found a way to reproduce this.
Some of them were produced by older qgis versions making it
easy to violate foreign key constraints and hard to recover.
This has been fixed.</span></p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr"> Possible mitigation: offer a "repair"
option in qgis. Through processing or "on the fly" upon
detection.<br>
</span></p>
<p>*<span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr"><span id=":ws.co" class="tL8wMe EMoHub"
style="text-align: left;" dir="ltr"> </span>Default value
magic replace values on insert (with no possibility to
pre-evaluate them)</span></p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr"> E.g. a global sequence like on postgres
would be nice. Can be worked around through default values in
qgis though.<br>
</span></p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr"> Possible mitigation: a)add it as a feature
to sqlite. b) use qgis default values. c) live with it.<br>
</span></p>
<p>*<span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr"><span id=":ws.co" class="tL8wMe EMoHub"
style="text-align: left;" dir="ltr"> </span>The requirement
for a single geometry column per table</span></p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr"> I just don't see a good reason to forbid
that</span></p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr"> Possible mitigation: a) alter the standard.
b) ignore the standard and patch the ogr implementation.<br>
</span></p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr"><br>
</span></p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr">I wonder how others feel about these topics.</span></p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr"><br>
</span></p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr">- Are there more pain points I forgot to
list?<br>
</span></p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr">- Do you see more approaches to mitigate
these problems?<br>
</span></p>
<p><span id=":ws.co" class="tL8wMe EMoHub" style="text-align:
left;" dir="ltr">- Is someone already working on these issues?<br>
</span></p>
<p><br>
</p>
<p>It would be great to have a standard file format that we can
fully trust. Let's make a reality check if GeoPackage can be
this format.</p>
<p>Best regards<br>
</p>
<div class="moz-signature">-- <br>
<meta http-equiv="content-type" content="text/html;
charset=UTF-8">
<div class="moz-signature">
<title></title>
<div class="moz-signature"> <span style="text-align: left;
color: #000000; font-family: 'Verdana', sans-serif;
font-size: 10pt">Matthias Kuhn</span><br>
<a href="mailto:matthias@opengis.ch" target="_blank"
moz-do-not-send="true"> <span style="text-align: left;
color: #000000; font-family: 'Verdana', sans-serif;
font-size: 8pt">matthias@opengis.ch</span> </a><br>
<span style="text-align: left; color: #000000; font-family:
'Verdana', sans-serif; font-size: 8pt"><a
href="tel:+41764356763" moz-do-not-send="true">+41 (0)76
435 67 63</a></span><br>
<div> <a href="http://www.opengis.ch"
moz-do-not-send="true"> <img moz-do-not-send="false"
src="cid:part5.0D5A235C.AE079197@carto.net"
alt="OPENGIS.ch Logo" class="" width="200" height="80"></a>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
QGIS-Developer mailing list
<a class="moz-txt-link-abbreviated" href="mailto:QGIS-Developer@lists.osgeo.org">QGIS-Developer@lists.osgeo.org</a>
List info: <a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a>
Unsubscribe: <a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/qgis-developer">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></pre>
</blockquote>
</body>
</html>