<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 6 déc. 2019 à 14:19, Matthias Kuhn <<a href="mailto:matthias@opengis.ch" target="_blank">matthias@opengis.ch</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Richard<br>
[..]<span class="gmail-im"><br>
Other proposals are very welcome as well. I don't insist on GeoPackage. <br>
All I do is being a bit skeptic that rolling our own format will <br>
magically solve problems that one hundred other formats did not solve :-)<br>
</span></blockquote><div><br></div><div>Wise words. I totally agree.  <div class="gmail-adL"><br><br></div></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 6 déc. 2019 à 14:19, Matthias Kuhn <<a href="mailto:matthias@opengis.ch">matthias@opengis.ch</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Richard<br>
<br>
On 12/6/19 2:07 PM, Richard Duivenvoorde wrote:<br>
> On 06/12/2019 07.58, Matthias Kuhn wrote:<br>
>> On 12/6/19 7:52 AM, Alexander Bruy wrote:<br>
>>> пт, 6 груд. 2019 о 08:44 Matthias Kuhn <<a href="mailto:matthias@opengis.ch" target="_blank">matthias@opengis.ch</a>> пише:<br>
>>>> Meanwhile, why not use a well known spatial data file format?<br>
>>> I can be wrong, but using spatial data formats can be lossy in some<br>
>>> cases,<br>
>>> e.g. shapefile/dbf has limits for the field name length and field<br>
>>> length. Some<br>
>>> other formats may lack support for some datatypes, like datetime etc.<br>
>>><br>
>>> Of course is there is a format which allow fast and lossless storage<br>
>>> we should<br>
>>> use it<br>
>> I think GeoPackage should be fairly stable for this kind of usage.<br>
> Well, yes, may be, but given I've seen some issue (locks/crashes etc<br>
> etc) with GeoPackages, and myself having issue with true<br>
> DateTime/TimeZones's in it... I thought to propose an alternative :-)<br>
<br>
Since these files are created as an output and no concurrent access is <br>
expected, I don't think there's a risk for locking issues here.<br>
<br>
For DateTime/TimeZones etc, are we sure we will be in a better situation <br>
with "our own" serialized format?<br>
<br>
> My impression is that the community is experiencing some drawbacks with<br>
> GeoPackage/SQLite, but maybe I'm wrong.<br>
<br>
Other proposals are very welcome as well. I don't insist on GeoPackage. <br>
All I do is being a bit skeptic that rolling our own format will <br>
magically solve problems that one hundred other formats did not solve :-)<br>
<br>
Regards<br>
<br>
Matthias<br>
<br>
><br>
> Regards,<br>
><br>
> Richard Duivenvoorde<br>
> _______________________________________________<br>
> QGIS-Developer mailing list<br>
> <a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
><br>
_______________________________________________<br>
QGIS-Developer mailing list<br>
<a href="mailto:QGIS-Developer@lists.osgeo.org" target="_blank">QGIS-Developer@lists.osgeo.org</a><br>
List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a><br>
Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-developer" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-developer</a></blockquote></div>