<div dir="ltr">Ciao A.<div><br></div><div>You wrote: </div><div>> <span style="font-family:arial,sans-serif;font-size:13px">Instead surely geopackage are no one strong point in elaboration so I'm not surprise that it is slow.</span></div>
<br style="font-family:arial,sans-serif;font-size:13px"><div>The bottleneck has been identified and Even resolved it.</div><div>As Jeremy reported it was the PRAGMA integrity_check which checked the whole file(!) when opening.</div>
<div>Now it remains to be tested how much faster opening of the GeoPackage is.</div><div><br></div><div>-S.</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">2014-05-17 13:44 GMT+02:00 aperi2007 <span dir="ltr"><<a href="mailto:aperi2007@gmail.com" target="_blank">aperi2007@gmail.com</a>></span>:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I have really difficulty to write of a so complex question in english.<br>
:(<br>
However try to explain.<br>
The shapefile is absolutely a bad solution for interchange usage.<br>
We experiment every day troubles. Sometimes the troubles was discovered after many time.<br>
The shapefile born as a simply format for a simply GIS product.<br>
SO the major request was "t be simpler possible".<br>
And infact the shapefile is really simply.<br>
The shp specs use the DBF format, but forgot that of DBF format there are many ,sometimes also really distinct to each other.<br>
(read the old clipper dbf spec and the old ashton-tate dbf spec to understand what this mean).<br>
<br>
So two shapefile could be not compatible at all.<br>
Also the shapefile don't sauy nothing of character-set usage.<br>
This is a bad question because often we must try more than one Character-set and hope to have no mixing of CS to retrieve correctly the texts.<br>
Also the shapefile don't has a NULL definition and also it allow the strange mix of MULTIPART and SIMPLY geometries.<br>
<br>
All this and so on are foe for a real interchangeable format because<br>
usually this mean that I export from a remote system , from a distinct GIS solution to every other solution.<br>
<br>
We every day use the gdal to transform (thx to gdal forever), but gdal cannot do miracles.<br>
<br>
A format born for interchange is surely the GML.<br>
It allow to define a different SRS for every geometry, also allow to host every typeof geometry ,<br>
but the GML failed in the market because the geometric definition was not well explained and so every GIS software<br>
choose to do its own interpretation of the geometrical tag in the GML.<br>
<br>
Obviously the postgis , oralce and so on are not really nterchange formats because they are only dump of the DBMS information.<br>
Another good candidate for interchange was the spatialite.<br>
The lastversion 4.2 is really good.<br>
It host metadata, host styles, host history and convert al to the UTF-8 internal.<br>
It has some limitation respect to the GML.<br>
The GML allow to have a distinct SRS for every geometry instead the spatialite allow a SRS for every table (dataset).<br>
<br>
But this limitation will not be a real limit today, perhaps in the next 2-3 year it will became a limit.<br>
<br>
But the spatialite has another limit for a good interchange format.<br>
It is also an elaboration unit.<br>
This is an advantage for me , but not for a real interchange format that need only host data.<br>
And give the elaboration phase to the GIS.<br>
This is a philosophy I don't like more, but has its own reasons .<br>
<br>
So why the geopackage is not a good work format ?<br>
The response is because it is a interchange format. The need of a work frmat are different from that of  a work format.<br>
The first need to but not redundant, more compact, but without loss any information or setting and compressable.<br>
<br>
The shapefile is nothing.<br>
It is not a good interchange format, and not a good working format.<br>
:)<br>
<br>
The spatialite is like a DBMS, it is a good work format.<br>
And has some point of interest in the interchange.<br>
The capability internally to speak with shapefile, postgres, dxf, wfs and GML/XML are good options.<br>
<br>
Also it hs a good elaboration capability.<br>
Is has no the limit of the shapefile and this is good.<br>
It host the styles and this is good.<br>
<br>
But has also some bad points.<br>
It is no so universal diffuse.<br>
Only qgis know it, and the qgis seem to have an own spatialite dialect not fully compatible with the original spatialite.<br>
The styles on spatialite are supported from qgis but they are incompatible respect at original spatialite version and this is a bad point.<br>
The metadata tables of spatialite are ignored from qgis.<br>
So the spatialite seem to be a chatedral in the desert.<br>
<br>
The spatialite will never to be a real interchange format if the only software to use it is qgis and the same qgis is not real compatible with the original spatialite spec.<br>
<br>
So the spatialite actually is a really good and strong work format .<br>
<br>
Instead surely geopackage are no one strong point in elaboration so I'm not surprise that it is slow.<br>
It don't born to do this work.<br>
:)<br>
<br>
A.<br>
<br>
Il 17/05/2014 11:24, Paolo Cavallini ha scritto:<div class="im HOEnZb"><br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Il 17/05/2014 11:03, Andrea Peri ha scritto:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Do you know the requirements of gpkg ?<br>
</blockquote>
They should be really minimal.<br>
This could help understanding speed issues:<br>
<a href="http://openjump.blogspot.fi/2014/02/openjump-plus-reads-ogc-geopackages.html" target="_blank">http://openjump.blogspot.fi/<u></u>2014/02/openjump-plus-reads-<u></u>ogc-geopackages.html</a><br>
All the best.<br>
</blockquote>
<br></div><div class="HOEnZb"><div class="h5">
______________________________<u></u>_________________<br>
Qgis-developer mailing list<br>
<a href="mailto:Qgis-developer@lists.osgeo.org" target="_blank">Qgis-developer@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-developer" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/qgis-<u></u>developer</a><br>
</div></div></blockquote></div><br></div>