<div>Sorry for bringing back an old thread.</div><div>I now have the data in SpatiaLite format and am using that reader (the yellowy cylinder icon), but unfortunately QGIS is doing the exact same thing as it did when it was in SQLite format. This is a smaller dataset (1,344,633 features), but QGIS still takes ~130 seconds to "add" it. However once loaded, panning is instantaneous (it has spatial indexes).</div>
<div>Looking Process Explorer, I believe QGIS is "reading" the entire dataset on "add".</div><div> </div><div>Am I doing something wrong? Is that icon the native reader?</div><div> </div><div>Thanks,</div><div>Jonathan<br><br><br><br></div><div class="gmail_quote">On 7 September 2012 13:45, Andreas Neumann <span dir="ltr"><<a href="mailto:a.neumann@carto.net" target="_blank">a.neumann@carto.net</a>></span> wrote:<br><blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">Hi,<br><br>I doubt that someone would work on it - if you report it as a bug.<br><br>The OGR way often offers an alternative loading to the native data providers in QGIS. As an example there is a native Postgis provider that offers more options compared to loading Postgis through OGR. As the native method is faster and more powerful, the QGIS developers won't spend time to improve the slower, alternative option.<br>
<br>The same is with SpatiaLite.<br><br>But yes - I would also consider it a bug if it is offered through OGR.<br><br>Andreas
<div class="im"><br><br>On Fri, 7 Sep 2012 13:05:20 +0100, Jonathan Moules wrote:<br></div><blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote"><div class="im">Hi Andreas,<br>Thanks for the prompt reply. FME 2013 (now in beta) has a SpatiaLite<br>writer in it which is what I'm going to try now I've seen how QGIS<br>handles this larger dataset (it handed the 73MB - ~200,000<br>
feature SQLite file with no problems at all).<br> <br>My email was more a - should it take this long just to add it? - kind<br>of queston. It seems like a bug to me but I figured I'd ask before<br>reporting it. I do appreciate its not the recommended way to store<br>
stuff but is this worth reporting as a bug? There certainly seems to<br>be something weird going on for it to take that long.<br>Cheers,<br>Jonathan<br><br></div>On 7 September 2012 12:51, Andreas Neumann wrote:<br><br>
<blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote"><div><div class="h5">Hi Jonathan,<br><br>The recommended way to store, load and save SQLite data is through<br>SpatiaLite. The other method you describe is through FDO and GDAL<br>(with other libraries in between), a less direct connection.<br>
<br>So please convert your data to SpatiaLite if you want to use it in<br>QGIS. OGR can do such conversions on the command line.<br><br>You can also talk to the FME people and tell them to support<br>SpatiaLite directly in FME. These people usually listen to their<br>
customers. If enough people demand SpatiaLite support they will<br>react and provide it with a future version.<br><br>Andreas<br><br>On Fri, 7 Sep 2012 12:44:55 +0100, Jonathan Moules wrote:<br><br><blockquote style="BORDER-LEFT:#ccc 1px solid;MARGIN:0px 0px 0px 0.8ex;PADDING-LEFT:1ex" class="gmail_quote">Hi list,<br>I have a large, ~9.5GB SQLite file (its FDO rather than<br>SpatiaLite;<br>I'm aware the later is preferred but FME 2012 doesn't write to<br>
them).<br>My problem is that just adding it seems to be a massive task for<br>QGIS.<br><br> <br>The database has 6 tables in it with a total of about 28.8 million<br>features.<br> <br>I do the following:<br>Add Vector Layer -> select file -> Click Ok.<br>
<br>QGIS now spends the next 9 minutes thrashing my hard disk.<br> <br>I then get the "select the layers you want to add" box pop up. I<br>select all the layers. QGIS then spends another 6 minutes<br>thrashing my<br>
hard drive before the first layer is added (I've already turned<br>off<br>"rendering" so there's no possiblity of drawing anything) - this<br>layer<br>having about 20million features.<br>Finally, 10 minutes after selecting the layers I want, and 20<br>
minutes<br>after I first clicked "add file", the layers are loaded to QGIS.<br> <br> <br>Conversely, SQLiteStudio can detect there are six tables<br>instantly. A<br>"select count(*) from TABLENAME" takes about 6 seconds to run<br>
against<br>the largest table (19,945,139 features). Thats all the information<br>thats required for the "select vector layers to add" apart from<br>geometry "type" which is a simple query to the geometry_columns<br>
table.<br>And again, that's just to get to the "select layers" page.<br> <br>So; should QGIS be taking this long to load a SQLite file? Is this<br>a<br>known issue?<br> <br>Panning around and actually using it is also a no-go for the<br>
largest<br>layer, I guess because this format doesn't have spatial indexing<br>(they're built dynamically). This I can understand, I'm just a<br>bit<br>confused as to why it takes to long to load in the first place.<br>
<br>Any thoughts?<br><br>Jonathan<br><br> This transmission is intended for the named addressee(s) only<br>and may<br>contain sensitive or protectively marked material up to<br>RESTRICTED and<br>should be handled accordingly. Unless you are the named addressee<br>
(or<br>authorised to receive it for the addressee) you may not copy or<br>use<br>it, or disclose it to anyone else. If you have received this<br>transmission in error please notify the sender immediately. All<br>email<br>
traffic sent to or from us, including without limitation all GCSX<br>traffic, may be subject to recording and/or monitoring in<br>accordance<br>with relevant legislation.<br></blockquote><br>--<br>--<br>Andreas Neumann<br>
Böschacherstrasse 10A<br>8624 Grüt (Gossau ZH)<br>Switzerland<br>______________________________<u></u>_________________<br>Qgis-user mailing list<br></div></div><a href="mailto:Qgis-user@lists.osgeo.org" target="_blank">Qgis-user@lists.osgeo.org</a> [1]<br>
<a href="http://lists.osgeo.org/mailman/listinfo/qgis-user" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/qgis-user</a> [2]<br></blockquote><div class="im"><br> This transmission is intended for the named addressee(s) only and may<br>contain sensitive or protectively marked material up to RESTRICTED and<br>should be handled accordingly. Unless you are the named addressee (or<br>
authorised to receive it for the addressee) you may not copy or use<br>it, or disclose it to anyone else. If you have received this<br>transmission in error please notify the sender immediately. All email<br>traffic sent to or from us, including without limitation all GCSX<br>
traffic, may be subject to recording and/or monitoring in accordance<br>with relevant legislation.<br><br><br></div>Links:<br>------<br>[1] mailto:<a href="mailto:Qgis-user@lists.osgeo.org" target="_blank">Qgis-user@lists.osgeo.<u></u>org</a><br>
[2] <a href="http://lists.osgeo.org/mailman/listinfo/qgis-user" target="_blank">http://lists.osgeo.org/<u></u>mailman/listinfo/qgis-user</a><br>[3] mailto:<a href="mailto:a.neumann@carto.net" target="_blank">a.neumann@carto.net</a><br>
</blockquote><div class="HOEnZb"><div class="h5"><br>-- <br>--<br>Andreas Neumann<br>Böschacherstrasse 10A<br>8624 Grüt (Gossau ZH)<br>Switzerland<br></div></div></blockquote></div><br><BR>
<BR>
This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.<BR>