[Qgis-developer] Geospackage Slow in QGIS

[aperi2007]

I have really difficulty to write of a so complex question in english.
:(
However try to explain.
The shapefile is absolutely a bad solution for interchange usage.
We experiment every day troubles. Sometimes the troubles was discovered 
after many time.
The shapefile born as a simply format for a simply GIS product.
SO the major request was "t be simpler possible".
And infact the shapefile is really simply.
The shp specs use the DBF format, but forgot that of DBF format there 
are many ,sometimes also really distinct to each other.
(read the old clipper dbf spec and the old ashton-tate dbf spec to 
understand what this mean).

So two shapefile could be not compatible at all.
Also the shapefile don't sauy nothing of character-set usage.
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.
Also the shapefile don't has a NULL definition and also it allow the 
strange mix of MULTIPART and SIMPLY geometries.

All this and so on are foe for a real interchangeable format because
usually this mean that I export from a remote system , from a distinct 
GIS solution to every other solution.

We every day use the gdal to transform (thx to gdal forever), but gdal 
cannot do miracles.

A format born for interchange is surely the GML.
It allow to define a different SRS for every geometry, also allow to 
host every typeof geometry ,
but the GML failed in the market because the geometric definition was 
not well explained and so every GIS software
choose to do its own interpretation of the geometrical tag in the GML.

Obviously the postgis , oralce and so on are not really nterchange 
formats because they are only dump of the DBMS information.
Another good candidate for interchange was the spatialite.
The lastversion 4.2 is really good.
It host metadata, host styles, host history and convert al to the UTF-8 
internal.
It has some limitation respect to the GML.
The GML allow to have a distinct SRS for every geometry instead the 
spatialite allow a SRS for every table (dataset).

But this limitation will not be a real limit today, perhaps in the next 
2-3 year it will became a limit.

But the spatialite has another limit for a good interchange format.
It is also an elaboration unit.
This is an advantage for me , but not for a real interchange format that 
need only host data.
And give the elaboration phase to the GIS.
This is a philosophy I don't like more, but has its own reasons .

So why the geopackage is not a good work format ?
The response is because it is a interchange format. The need of a work 
frmat are different from that of  a work format.
The first need to but not redundant, more compact, but without loss any 
information or setting and compressable.

The shapefile is nothing.
It is not a good interchange format, and not a good working format.
:)

The spatialite is like a DBMS, it is a good work format.
And has some point of interest in the interchange.
The capability internally to speak with shapefile, postgres, dxf, wfs 
and GML/XML are good options.

Also it hs a good elaboration capability.
Is has no the limit of the shapefile and this is good.
It host the styles and this is good.

But has also some bad points.
It is no so universal diffuse.
Only qgis know it, and the qgis seem to have an own spatialite dialect 
not fully compatible with the original spatialite.
The styles on spatialite are supported from qgis but they are 
incompatible respect at original spatialite version and this is a bad point.
The metadata tables of spatialite are ignored from qgis.
So the spatialite seem to be a chatedral in the desert.

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.

So the spatialite actually is a really good and strong work format .

Instead surely geopackage are no one strong point in elaboration so I'm 
not surprise that it is slow.
It don't born to do this work.
:)

A.

Il 17/05/2014 11:24, Paolo Cavallini ha scritto:
> Il 17/05/2014 11:03, Andrea Peri ha scritto:
>> Do you know the requirements of gpkg ?
> They should be really minimal.
> This could help understanding speed issues:
> http://openjump.blogspot.fi/2014/02/openjump-plus-reads-ogc-geopackages.html
> All the best.