[Qgis-user] Diagnosing QGIS slowdown (Windows)

[Mike Flannigan]

I don't think this is your problem, but I'll mention
it for others.  If you have a geojson file that you want
to import into QGIS and it has only 10 newlines in it,
QGIS can have trouble with files that have thousands of
characters on a single line.  It would much rather have
10,000 newlines in the file.  It will still import the
geojson file with only 10 newlines in it, and work with
it.  But it will bog things down eventually.

So if you have this:

{
"type": "FeatureCollection",
"crs": { "type": "name", "properties": { "name": 
"urn:ogc:def:crs:OGC:1.3:CRS84" } },
"features": [

{ "type": "Feature", "properties": { "id": 1, "name": "Sylamore" }, 
"geometry": { "type": "LineString", "coordinates": [ [ 
-92.3184166666668, 36.0565333333334 ],  [ -92.3181000000001, 
36.0565666666668 ],  [ -92.3179166666668, 36.0567166666668 ],  [ 
-92.3174333333334, 36.0568666666668 ],  [ -92.3169666666668, 
36.0570666666668 ],  [ -92.3167666666668, 36.0572333333334 ],  [ 
-92.3165166666668, 36.0576333333334 ],  [ -92.3163500000001, 
36.0577666666668 ],  [ -92.3161166666668, 36.0577500000001 ],  [ 
-92.3158333333334, 36.0577833333334 ], . . .



Change it to this before importing into QGIS:

{
"type": "FeatureCollection",
"crs": { "type": "name", "properties": { "name": 
"urn:ogc:def:crs:OGC:1.3:CRS84" } },
"features": [

{ "type": "Feature", "properties": { "id": 1, "name": "Sylamore" }, 
"geometry": { "type": "LineString", "coordinates": [ [ 
-92.3184166666668, 36.0565333333334 ],
   [ -92.3181000000001, 36.0565666666668 ],
   [ -92.3179166666668, 36.0567166666668 ],
   [ -92.3174333333334, 36.0568666666668 ],
   [ -92.3169666666668, 36.0570666666668 ],
   [ -92.3167666666668, 36.0572333333334 ],
   [ -92.3165166666668, 36.0576333333334 ],
   [ -92.3163500000001, 36.0577666666668 ],
   [ -92.3161166666668, 36.0577500000001 ],
. . .



Mike


On 12/17/20 8:19 AM, qgis-user-request at lists.osgeo.org wrote:
> Helpful, thanks.
>
> I've now created a separate project which uses a (layout)-rendered map from
> the main project, and where I selectively pull in individual layers for
> editing from the gpkg. That works fine. (I like @baswein's idea of 2
> instances drag-and-drop, but I've been fine so far only dragging within one
> instance, but from the main project .qgz opened up in the Browser; the
> effect is the same)
>
> @Nicolas, so far I've tried creating a single brand new new .shp (non .gpkg)
> layer. The general UI sluggishness (in the main project) is the same, as is
> the long delay exiting edit mode. But the sluggishness editing a new
> feature's attribute form is gone. Ditto for creating a new layer inside my
> main .gpkg file. So it's not*directly*  related to gpkg vs shp, though if
> I'm experiencing problems working with gpkg files overall, especially
> complex multi-layer reads from gpkg, that would still be consistent. I
> haven't bypassed gpkg completely.
>
> Given the alternate-project workaround, I'll muddle through for a few days,
> and next week try if 3.16.2 miraculously fixes the issue. If not, I'll
> rebuild my project, which by using saved styles/layer defn files and adding
> via the browser from the main project won't be that huge a hassle. Still
> some, of course, as I need to fiddle with layer groups and ordering, joins,
> project variables and the like.
>
> Maybe with the new cross-project copying/opening functionality, I should
> rebuild the project as multiple, leaner ones anyway. I have accreted about
> 50 vector layers and 30 raster ones, which turn on and off via themes,
> exclusive groups, and temporal ranges. Maybe now's the time to rebuild as
> multiple much simpler projects merely accessing the same data store (and
> saved styles).