Ciao A. You wrote: > Instead surely geopackage are no one strong point in elaboration so I'm not surprise that it is slow.
The bottleneck has been identified and Even resolved it. As Jeremy reported it was the PRAGMA integrity_check which checked the whole file(!) when opening. Now it remains to be tested how much faster opening of the GeoPackage is. -S. 2014-05-17 13:44 GMT+02:00 aperi2007 <aperi2...@gmail.com>: > > 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. >> > > _______________________________________________ > Qgis-developer mailing list > Qgis-developer@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/qgis-developer >
_______________________________________________ Qgis-developer mailing list Qgis-developer@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/qgis-developer
