Hi there
Due to imminent deadlines on a project I was working on, I had to leave
the issue and just press on with a VM running an older version.
I am currently building some test VMs and projects and hope to log this
issue in the bug tracker in the next few days.
On 2/02/20 5:25 am, Jonathan Moules wrote:
Hi Patrick,
I'd suggest reporting this to the QGIS bug tracker as a regression.
Cheers,
Jonathan
On 2020-02-01 07:20, Patrick Dunford wrote:
Further investigation and comment
Since recently installing Qgis 3.4.15 or 3.4.14 on some of my
computers running Debian 10, I immediately began to see a trend of
the software exhibiting an increased tendency to crash when working
with certain WMTS layers that I had previously worked with
extensively over recent weeks for mapping purposes.
After attempting numerous changes including special versions of
projects containing no file based raster layers and only containing
one WMTS layer at a time and being unable to use the software
regardless I created a virtual machine running Debian 9 which has the
latest version available for that platform, 3.4.4. This has resulted
in immediate major improvement in the reliability of the software to
the point I can resume using it without the numerous crashes of the
software that have been noted recently, especially in the last week
approximately.
On 27/01/20 1:19 am, Patrick Dunford wrote:
Good day to all.
Not so long ago I wrote a post about issues handling large numbers
of raster files. This results from what appears to be an
architectural design limitation of Qgis in that it only has enough
resources available for a certain (unknown) number of raster layers
and does not have any effective system for dealing with the
exhaustion of these resources.
I also noted that the software does not appear to have the ability
to use the swap (virtual memory) resources within a system to deal
with the apparent exhaustion of resources, as other software would.
For example, Gimp which I use for graphical editing is able to
handle certain projects using a swap space of 200 GB, which consists
of 32 GB of physical RAM and the rest in SSD. It is not unusual with
some of these graphics projects to have 100 GB or more of swap space
in use, without crashing the system. (This being possible since Gimp
2.10 with its ability to write files of more than 4 GB)
Whilst it is possible to manage the number of layers with file based
rasters, this cannot be done with a WMTS server because there is no
way I am aware of to manage the number of layers that can be
downloaded from the server.
Version 2.18 and earlier almost never crashed with excess layers,
usually all that would happen is a layer would be displayed with
invalid data. However, crashes have become the norm with 3.x
versions of software.
It seems to me there is a big architectural problem in the software
with its inability to utilise the full resources of the system in
order to process the number of layers that a WMTS server is capable
of issuing.
_______________________________________________
Qgis-user mailing list
[email protected]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
_______________________________________________
Qgis-user mailing list
[email protected]
List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
