<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Thanks for the clarification Andreas, indeed there was a
misunderstanding on my end.</p>
<p>That's admittedly a pain point with GPKG, I hope this can be
resolved in future versions of the spec.</p>
<p>But let's be honest, in QGIS we are not much better yet,
integration of additional geometry columns is not very polished.
We have a "main" geometry column to work with and "secondary"
geometry columns which can be accessed to some degree. A concept
which we can tack onto GPKG (or any format with no field content
limitation -- guess who just dropped out of the candidate
formats) as well.<br>
</p>
<p>Matthias<br>
</p>
<div class="moz-cite-prefix">On 12/9/19 10:29 AM, Andreas Neumann
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:2adfd1c3b0de040ff202662fdfd827d1@carto.net">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<p>If I may chime in: I think Matthias and Nyall are talking about
two different things:</p>
<p>Matthias: Multigeometry data types, like MultiPolygon,
MultiLinestring, etc. - that is well supported by Geopackage</p>
<p>Nyall: mulitple geometry columns - that works in Postgis,
Interlis and some other formats, but not Geopackage. Yes, there
are some valid use cases, where the same object should allow
different representations, e.g. for different scales, or as
point and polygon.</p>
<p>Greetings,<br>
Andreas</p>
<p id="reply-intro">On 2019-12-09 10:22, Matthias Kuhn wrote:</p>
<blockquote type="cite" style="padding: 0 0.4em; border-left:
#1010ff 2px solid; margin: 0">
<div class="pre" style="margin: 0; padding: 0; font-family:
monospace"><br>
<span style="white-space: nowrap;">On 12/9/19 10:09 AM, Nyall Dawson wrote:</span>
<blockquote type="cite" style="padding: 0 0.4em; border-left:
#1010ff 2px solid; margin: 0"><span style="white-space:
nowrap;">On Mon, 9 Dec 2019 at 18:07, Matthias Kuhn <<a
href="mailto:matthias@opengis.ch" moz-do-not-send="true">matthias@opengis.ch</a>> wrote:</span>
<blockquote type="cite" style="padding: 0 0.4em;
border-left: #1010ff 2px solid; margin: 0"><span
style="white-space: nowrap;">On 12/8/19 11:35 PM, Nyall Dawson wrote:</span>
<blockquote type="cite" style="padding: 0 0.4em;
border-left: #1010ff 2px solid; margin: 0"><span
style="white-space: nowrap;">On Fri, 6 Dec 2019 at 23:19, Matthias Kuhn <<a
href="mailto:matthias@opengis.ch"
moz-do-not-send="true">matthias@opengis.ch</a>> wrote:</span>
<blockquote type="cite" style="padding: 0 0.4em;
border-left: #1010ff 2px solid; margin: 0"><span
style="white-space: nowrap;">Other proposals are very welcome as well. I don't insist on GeoPackage.</span><br>
<span style="white-space: nowrap;">All I do is being a bit skeptic that rolling our own format will</span><br>
<span style="white-space: nowrap;">magically solve problems that one hundred other formats did not solve :-)</span><br>
<br>
</blockquote>
<span style="white-space: nowrap;">The issue is that the memory provider, by design, MUST be a lossless</span><br>
<span style="white-space: nowrap;">reflection of all the capabilities offered in QGIS vector layers. That</span><br>
<span style="white-space: nowrap;">means support for every geometry type, and field type handled by QGIS.</span><br>
<span style="white-space: nowrap;">Geopackage might be capable of that now... but it won't always be, due</span><br>
<span style="white-space: nowrap;">to the inherent limitations of that format. (No multi-geometry</span><br>
<span style="white-space: nowrap;">support, no mixed CRS geometry support, no support for advanced field</span><br>
<span style="white-space: nowrap;">types like range/interval fields, etc).</span></blockquote>
<span style="white-space: nowrap;">Having our own binary format makes sense from a full QGIS data type</span><br>
<span style="white-space: nowrap;">support perspective.</span><br>
<br>
<span style="white-space: nowrap;">As mentioned before, I don't insist on GeoPackage (but now that you say</span><br>
<span style="white-space: nowrap;">it, does it not have multi-geometry support? According to the specs it</span><br>
<span style="white-space: nowrap;">should. And just like we can binary dump all our field formats into our</span><br>
<span style="white-space: nowrap;">own binary file, we could dump them into any file, like e.g. GeoPackage).</span></blockquote>
<span style="white-space: nowrap;">Nope: <a
href="https://www.geopackage.org/guidance/modeling.html"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true">https://www.geopackage.org/guidance/modeling.html</a></span><br>
<br>
<span style="white-space: nowrap;">"Allowing multiple geometries per feature table would compromise</span><br>
<span style="white-space: nowrap;">GeoPackage's position in the GIS application ecosystem"</span><br>
<br>
<span style="white-space: nowrap;">(FWIW, that page is ridiculous, arrogant, and completely neglects some</span><br>
<span style="white-space: nowrap;">very valid use cases)</span></blockquote>
<br>
The geopackage specs say otherwise (<a
href="http://www.geopackage.org/spec/#geometry_types"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true">http://www.geopackage.org/spec/#geometry_types</a>)
and so does our very own dialog to create geopackage.<br>
<br>
If someone wrote modelling guidelines, that was probably meant
as best practice (on which one can agree or not).<br>
<br>
<blockquote type="cite" style="padding: 0 0.4em; border-left:
#1010ff 2px solid; margin: 0"><br>
<blockquote type="cite" style="padding: 0 0.4em;
border-left: #1010ff 2px solid; margin: 0">
<blockquote type="cite" style="padding: 0 0.4em;
border-left: #1010ff 2px solid; margin: 0"><span
style="white-space: nowrap;">I don't think it's useful to even think of rolling our own data format</span><br>
<span style="white-space: nowrap;">-- that's NOT what's required here. All that we need is a way of</span><br>
<span style="white-space: nowrap;">paging the currently in-memory storage of features used by the memory</span><br>
<span style="white-space: nowrap;">provider to disk when required. This disk based paging would be</span><br>
<span style="white-space: nowrap;">totally temporary (always deleted when the layer is removed), have no</span><br>
<span style="white-space: nowrap;">requirement for a stable binary format (we could change the paging</span><br>
<span style="white-space: nowrap;">binary structure version by version if needed), and absolutely no need</span><br>
<span style="white-space: nowrap;">for ANY other programs to be able to parse or interpret. It's not a</span><br>
<span style="white-space: nowrap;">data format at all -- it's just a disk based reflection of what we</span><br>
<span style="white-space: nowrap;">currently store in RAM, along with some smart indexing to optimize</span><br>
<span style="white-space: nowrap;">access.</span></blockquote>
<span style="white-space: nowrap;">Implementing indexing and paged loading of requested data resolved by an</span><br>
<span style="white-space: nowrap;">index sound like fun, do you think the effort (or the risks involved) is</span><br>
<span style="white-space: nowrap;">smaller than tacking support for the missing bits to another format?</span></blockquote>
<span style="white-space: nowrap;">Honestly, yes. I suspect it's more work upfront, but less long-term</span><br>
<span style="white-space: nowrap;">pain of applying hacks on hacks to try to duct tape functionality into</span><br>
<span style="white-space: nowrap;">a standard format.</span></blockquote>
<br>
Wasn't it just thought as a band aid until flatgeobuf comes
(riding on a unicorn) to solve all our issues?<br>
<br>
<blockquote type="cite" style="padding: 0 0.4em; border-left:
#1010ff 2px solid; margin: 0"><br>
<blockquote type="cite" style="padding: 0 0.4em;
border-left: #1010ff 2px solid; margin: 0"><span
style="white-space: nowrap;">I am counting the days until someone wants to recover from one of these</span><br>
<span style="white-space: nowrap;">files ;)</span></blockquote>
<span style="white-space: nowrap;">As soon as anyone tries that, I'm closing the bug report/feature</span><br>
<span style="white-space: nowrap;">request as "hell-no-wont-fix" ;)</span></blockquote>
<br>
That will be a good move if we follow this path. But I still
think accessible formats have their merits.<br>
<br>
Matthias<br>
<br>
_______________________________________________<br>
<span style="white-space: nowrap;">QGIS-Developer mailing list</span><br>
<span style="white-space: nowrap;"><a
href="mailto:QGIS-Developer@lists.osgeo.org"
moz-do-not-send="true">QGIS-Developer@lists.osgeo.org</a></span><br>
<span style="white-space: nowrap;">List info: <a
href="https://lists.osgeo.org/mailman/listinfo/qgis-developer"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></span><br>
<span style="white-space: nowrap;">Unsubscribe: <a
href="https://lists.osgeo.org/mailman/listinfo/qgis-developer"
target="_blank" rel="noopener noreferrer"
moz-do-not-send="true">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></span></div>
</blockquote>
<p><br>
</p>
</blockquote>
</body>
</html>