<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<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">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">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"> <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">+41 (0)76 435 67 63</a></span><br>
<div> <a href="http://www.opengis.ch"> <img
moz-do-not-send="false"
src="cid:part3.96363975.06974A43@opengis.ch"
alt="OPENGIS.ch Logo" width="200" height="80"></a> </div>
</div>
</div>
</div>
</body>
</html>