<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Very well. I am glad we are at the same boat here ;-)</p>
<p>Andreas<br>
</p>
<div class="moz-cite-prefix">Am 08.05.20 um 12:43 schrieb Matthias
Kuhn:<br>
</div>
<blockquote type="cite"
cite="mid:6e7e9c88-af43-2ea0-c364-83a6ac3ed376@opengis.ch">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>Hi Andreas</p>
<p>Thanks for also pointing out this question. I would like to
completely focus on b) for now to not disperse the discussion
too much.</p>
<p>If it comes down to unresolvable problems we can still go for
d).</p>
<p>But let's keep that for later.</p>
<p>Matthias<br>
</p>
<div class="moz-cite-prefix">On 5/8/20 11:59 AM, Andreas Neumann
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:77fa2b0a-be80-7f65-2d64-f267c2930962@carto.net">
<meta http-equiv="Content-Type" content="text/html;
charset=UTF-8">
<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.0912AC31.956B1BD2@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" moz-do-not-send="true">QGIS-Developer@lists.osgeo.org</a>
List info: <a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" moz-do-not-send="true">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" moz-do-not-send="true">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></pre>
</blockquote>
<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" moz-do-not-send="true">QGIS-Developer@lists.osgeo.org</a>
List info: <a class="moz-txt-link-freetext" href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" moz-do-not-send="true">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" moz-do-not-send="true">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></pre>
</blockquote>
</blockquote>
</body>
</html>