<div dir="ltr"><div><font color="#000000" face="Roboto, sans-serif"><span style="font-size:14px;line-height:22px">This from the ogr2ogr documentation[1] may be relevant:</span></font></div><div><span style="color:rgb(0,0,0);font-family:Roboto,sans-serif;font-size:14px;line-height:22px"><br></span></div><span style="color:rgb(0,0,0);font-family:Roboto,sans-serif;font-size:14px;line-height:22px">"When writing into transactional DBMS (SQLite/PostgreSQL,MySQL, etc...), it might be beneficial to increase the number of INSERT statements executed between BEGIN TRANSACTION and COMMIT TRANSACTION statements. This number is specified with the -gt option. For example, for SQLite, explicitly defining </span><b style="color:rgb(0,0,0);font-family:Roboto,sans-serif;font-size:14px;line-height:22px">-gt 65536</b><span style="color:rgb(0,0,0);font-family:Roboto,sans-serif;font-size:14px;line-height:22px"> ensures optimal performance"</span><br><div><br></div><div><span style="color:rgb(0,0,0);font-family:Roboto,sans-serif;font-size:14px;line-height:22px">Mike</span></div><div><span style="color:rgb(0,0,0);font-family:Roboto,sans-serif;font-size:14px;line-height:22px">[1] </span><font color="#000000" face="Roboto, sans-serif"><span style="font-size:14px;line-height:22px"><a href="http://www.gdal.org/ogr2ogr.html">http://www.gdal.org/ogr2ogr.html</a></span></font></div><div><span style="color:rgb(0,0,0);font-family:Roboto,sans-serif;font-size:14px;line-height:22px"><br></span></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 22, 2016 at 5:01 PM, Stefan Keller <span dir="ltr"><<a href="mailto:sfkeller@gmail.com" target="_blank">sfkeller@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Hi Frederik and Jukka<br>
<br>
Before I try give answers to performance let's be aware that we're (at<br>
least I am) speaking about a "desktop exchange format", not a storage<br>
fomat for GIS processing.<br>
<br>
But Frederik's comment piqued my curiosity and I did some quick comparison.<br>
I generated 1 mio. records in PostsGIS with this table<br>
CREATE TABLE benchmark (id serial primary key, txt varchar(32), geom<br>
geometry(point,4326) );<br>
<br>
Then I used OGR2OGR to create the following three file formats:<br>
GeoPackage (using 73.9 MB disk space), Shapefiles (dbf/shp/shx 117 MB)<br>
and Spatialite (173 MB).<br>
<br>
Creation time of GeoPackage was 18 sec., Shapefile 21 sec. and<br>
Spatialite 1 min 51 sec.<br>
So, GeoPackage is a bit faster than Shapefiles and significantly<br>
(about 37%) smaller in size.<br>
Spatialite in fact consumes much more disk space than Shapefile and<br>
GeoPackage, and Spatialite is several times slower for creation time.<br>
<br>
This could explain the preformance issues of Spatialite Frederic mentioned.<br>
<span class=""><font color="#888888"><br>
:Stefan<br>
</font></span><div class=""><div class="h5"><br>
2016-03-22 13:56 GMT+01:00 Jukka Rahkonen <<a href="mailto:jukka.rahkonen@latuviitta.fi">jukka.rahkonen@latuviitta.fi</a>>:<br>
> Frederik Ramm <frederik <at> <a href="http://remote.org" rel="noreferrer" target="_blank">remote.org</a>> writes:<br>
><br>
>><br>
>> Hi,<br>
>><br>
>> On 03/20/2016 10:56 PM, Stefan Keller wrote:<br>
>> > But Shapefile remains an oldtimer with more drawbacks than limited<br>
>> > field names; see [1].<br>
>> > GeoJSON (ascii) and GeoPackages (binary) are formats which are more<br>
>> > suited for the job.<br>
>> > I still have hope that JOSM will be able to read those vector formats too.<br>
>><br>
>> Frankly, whenever I venture into the brave new world of Spatialite, I<br>
>> come back to good old shape files after a while for performance reasons.<br>
>> I'm not sure if Geopackage has significant performance improvements over<br>
>> simple Spatialite but if it hasn't then my recommendation for simple GIS<br>
>> processing is certainly to stick with shape files for the time being -<br>
>> despite all their shortcomings.<br>
><br>
><br>
> Hi Frederic,<br>
><br>
> I would like to receive some sample data, exact way to reproduce some of<br>
> your ventures and cold numbers about the speed you have experienced.<br>
> Spatialite does have it's limits but for plain selects with spatial and<br>
> attribute filters it can well outperform both shapefiles and PostGIS.<br>
><br>
> I keep most vector data for WMS services in Spatialite or GeoPackage due to<br>
> the already mentioned and some other reasons:<br>
> - supports long attribute names<br>
> - supports strings longer than 255 characters<br>
> - supports SQL<br>
> - supports attribute indexes<br>
> - much less encoding problems due to UTF-8<br>
> - one single file vs. a bunch of files in shapefile, perhaps even split to<br>
> separate bunches for points, lines and polygons.<br>
><br>
> For me SpatiaLite is a little bit slower than shapefiles if only spatial<br>
> filter (BBOX) is used but usually faster if also attribute filters are<br>
> involved, especially if more than one field is needed in filters (Shapefiles<br>
> can be sorted by one attribute only). Of course spatialite must have indexes<br>
> which suit the queries and when it comes to spatial index, the client must<br>
> know how to utilize the table based R-Tree index. I also recommend to VACUUM<br>
> once the database is ready to use.<br>
><br>
> Many spatial operations are relatively slow in Spatialite and I don't<br>
> usually utilize them on-the-fly with WMS server. Instead, I run the<br>
> algorithm once and store the result into a new table because a few<br>
> mega/gigabytes of additional disk space is not crucial on the server.<br>
> However, such operations tend to be slow also if shapefiles are used as<br>
> source data.<br>
><br>
> Write performance especially with concurrent writes is another story. I am<br>
> talking about read-only operations. I know that I am writing empty words as<br>
> far as I do not include reproducible facts but I am willing to join to a<br>
> controlled test if someone is organizing such.<br>
><br>
> -Jukka Rahkonen-<br>
><br>
><br>
><br>
><br>
> _______________________________________________<br>
> talk mailing list<br>
> <a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br>
> <a href="https://lists.openstreetmap.org/listinfo/talk" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk</a><br>
<br>
_______________________________________________<br>
talk mailing list<br>
<a href="mailto:talk@openstreetmap.org">talk@openstreetmap.org</a><br>
<a href="https://lists.openstreetmap.org/listinfo/talk" rel="noreferrer" target="_blank">https://lists.openstreetmap.org/listinfo/talk</a><br>
</div></div></blockquote></div><br></div></div>