Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only
I haven't checked to see if it can be installed on Home as I have a Win10Pro computer. However I do not recommend the NFS client for Windows since it is not native and tricky to set up. I would not have any certainty about its performance. My Windows 10 computer is usually connected to the rest of my network using the inbuilt SMB support to a separate Samba server running on the host alongside NFS. On 19/03/23 10:02, David Strip wrote: On 3/18/2023 1:50 PM, Patrick Dunford via QGIS-User wrote: but I use NFS, which is not available on Windows (my computers run Linux) NFS is available on Win 10 and 11 in the Pro and Enterprise versions, but not the Home version. I think it is not on by default, however. ___ QGIS-User mailing list QGIS-User@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only
I would not contemplate using NFS on Windows as NFS support is not native in Windows. It could create a lot of other issues. It is easier for me in my situation to connect my single Windows computer to my network via a separate Samba share. Best outcome is to change working practices as per other comments. On 20/03/23 21:59, Árni Geirsson wrote: Thank you all who have responded over the weekend with helpful suggestions. I wish I could use Linux on all the office computers but that is not realistic. But what I have now learned is that a) I could try NFS on Windows and b) there might be some hope in tweaking Samba. Both are interesting threads to pursue. If it is true that the problem with geopackages/sqlite that I raised in the beginning does not exist when shared under NFS, I have to conclude that there is some bad chemistry between Samba and sqlite. Maybe that is something the sqlite developers can resolve. Árni On Sat, 18 Mar 2023 at 21:07, David Strip via QGIS-User wrote: On 3/18/2023 1:50 PM, Patrick Dunford via QGIS-User wrote: but I use NFS, which is not available on Windows (my computers run Linux) NFS is available on Win 10 and 11 in the Pro and Enterprise versions, but not the Home version. I think it is not on by default, however. ___ QGIS-User mailing list QGIS-User@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user ___ QGIS-User mailing list QGIS-User@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only
Thank you for the suggestion - I always use the latest versions and this problem is certainly present in these. Árni On Mon, 20 Mar 2023 at 09:40, Johannes Kröger (WhereGroup) < johannes.kroe...@wheregroup.com> wrote: > Since your problem seems to vanish if your files are read-only: Are you > using a modern QGIS and GDAL? And were your GeoPackages created by that > combination? Older versions (and apparently GPKGs created by older > versions) used some kind of write-access to any opened GPKG, even if you > weren't editing, and iirc a timestamp was updated. This might lead to extra > network calls to your share, maybe even re-uploading the whole file all the > time and mght be the issue here. With modern QGIS+GDAL opening GPKGs > without editing should not do that anymore. > > See https://github.com/qgis/QGIS/issues/23991 > > Maybe sniff your network traffic to check what really is going on. > > Cheers, Hannes > Am 20.03.23 um 09:59 schrieb Árni Geirsson via QGIS-User: > > Thank you all who have responded over the weekend with helpful > suggestions. I wish I could use Linux on all the office computers but that > is not realistic. But what I have now learned is that a) I could try NFS on > Windows and b) there might be some hope in tweaking Samba. Both are > interesting threads to pursue. > If it is true that the problem with geopackages/sqlite that I raised in > the beginning does not exist when shared under NFS, I have to conclude that > there is some bad chemistry between Samba and sqlite. Maybe that is > something the sqlite developers can resolve. > > Árni > > > On Sat, 18 Mar 2023 at 21:07, David Strip via QGIS-User < > qgis-user@lists.osgeo.org> wrote: > >> On 3/18/2023 1:50 PM, Patrick Dunford via QGIS-User wrote: >> >> but I use NFS, which is not available on Windows (my computers run Linux) >> >> >> NFS is available on Win 10 and 11 in the Pro and Enterprise versions, but >> not the Home version. >> I think it is not on by default, however. >> ___ >> QGIS-User mailing list >> QGIS-User@lists.osgeo.org >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user >> > > ___ > QGIS-User mailing listqgis-u...@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-user > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user > > -- > Johannes Kröger / GIS-Entwickler/-Berater > > ** > FOSSGIS Konferenz > 15.-18. März 2023 in Berlinhttps://fossgis-konferenz.de/2023/ > > WhereGroup-Beiträge auf der > FOSSGIShttps://wheregroup.com/unternehmen/aktuelles/ > ** > > WhereGroup GmbH > c/o KK03 GmbH > Lange Reihe 29 > 20099 Hamburg > Germany > > Tel: +49 (0)228 / 90 90 38 - 36 > Fax: +49 (0)228 / 90 90 38 - 11 > johannes.kroe...@wheregroup.comwww.wheregroup.com > Geschäftsführer: > Olaf Knopp, Peter Stamm > Amtsgericht Bonn, HRB 9885 > --- > > ___ QGIS-User mailing list QGIS-User@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only
Since your problem seems to vanish if your files are read-only: Are you using a modern QGIS and GDAL? And were your GeoPackages created by that combination? Older versions (and apparently GPKGs created by older versions) used some kind of write-access to any opened GPKG, even if you weren't editing, and iirc a timestamp was updated. This might lead to extra network calls to your share, maybe even re-uploading the whole file all the time and mght be the issue here. With modern QGIS+GDAL opening GPKGs without editing should not do that anymore. See https://github.com/qgis/QGIS/issues/23991 Maybe sniff your network traffic to check what really is going on. Cheers, Hannes Am 20.03.23 um 09:59 schrieb Árni Geirsson via QGIS-User: Thank you all who have responded over the weekend with helpful suggestions. I wish I could use Linux on all the office computers but that is not realistic. But what I have now learned is that a) I could try NFS on Windows and b) there might be some hope in tweaking Samba. Both are interesting threads to pursue. If it is true that the problem with geopackages/sqlite that I raised in the beginning does not exist when shared under NFS, I have to conclude that there is some bad chemistry between Samba and sqlite. Maybe that is something the sqlite developers can resolve. Árni On Sat, 18 Mar 2023 at 21:07, David Strip via QGIS-User wrote: On 3/18/2023 1:50 PM, Patrick Dunford via QGIS-User wrote: but I use NFS, which is not available on Windows (my computers run Linux) NFS is available on Win 10 and 11 in the Pro and Enterprise versions, but not the Home version. I think it is not on by default, however. ___ QGIS-User mailing list QGIS-User@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user ___ QGIS-User mailing list QGIS-User@lists.osgeo.org List info:https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe:https://lists.osgeo.org/mailman/listinfo/qgis-user -- Johannes Kröger / GIS-Entwickler/-Berater ** FOSSGIS Konferenz 15.-18. März 2023 in Berlin https://fossgis-konferenz.de/2023/ WhereGroup-Beiträge auf der FOSSGIS https://wheregroup.com/unternehmen/aktuelles/ ** WhereGroup GmbH c/o KK03 GmbH Lange Reihe 29 20099 Hamburg Germany Tel: +49 (0)228 / 90 90 38 - 36 Fax: +49 (0)228 / 90 90 38 - 11 johannes.kroe...@wheregroup.com www.wheregroup.com Geschäftsführer: Olaf Knopp, Peter Stamm Amtsgericht Bonn, HRB 9885 --- ___ QGIS-User mailing list QGIS-User@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only
Thank you all who have responded over the weekend with helpful suggestions. I wish I could use Linux on all the office computers but that is not realistic. But what I have now learned is that a) I could try NFS on Windows and b) there might be some hope in tweaking Samba. Both are interesting threads to pursue. If it is true that the problem with geopackages/sqlite that I raised in the beginning does not exist when shared under NFS, I have to conclude that there is some bad chemistry between Samba and sqlite. Maybe that is something the sqlite developers can resolve. Árni On Sat, 18 Mar 2023 at 21:07, David Strip via QGIS-User < qgis-user@lists.osgeo.org> wrote: > On 3/18/2023 1:50 PM, Patrick Dunford via QGIS-User wrote: > > but I use NFS, which is not available on Windows (my computers run Linux) > > > NFS is available on Win 10 and 11 in the Pro and Enterprise versions, but > not the Home version. > I think it is not on by default, however. > ___ > QGIS-User mailing list > QGIS-User@lists.osgeo.org > List info: https://lists.osgeo.org/mailman/listinfo/qgis-user > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user > ___ QGIS-User mailing list QGIS-User@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only
On 3/18/2023 1:50 PM, Patrick Dunford via QGIS-User wrote: but I use NFS, which is not available on Windows (my computers run Linux) NFS is available on Win 10 and 11 in the Pro and Enterprise versions, but not the Home version. I think it is not on by default, however. ___ QGIS-User mailing list QGIS-User@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only
Thanks for this. You've helped convince me I need to keep a big cabinet with a row of "huge" tower chassises in it to store all my map data instead of forking out to get one of those wee little NASs and save a bit of space :) using Linux on my computer and NFS for networking when I need to open files on a different computer because the usual one is having some sort of problem. lol On 17/03/23 03:39, jhubbslist--- via QGIS-User wrote: You'd only be "living with it" because you choose to use the wrong tools for the work and refuse to use the right ones. In this case, I see the "wrong tools" here as 1) network-shared files for common r/w access 2) the SMB/CIFS protocol in general 3) appliance-type file servers are trash. You can try to make things better by standing up a proper Linux-based file server and using NFS instead of SMB/CIFS but 1) is enough of a problem that you'd only be throwing good work after bad. If it suits your use cases, you might try implementing something like git - which is after a fashion just another networked file-sharing protocol - and use check-out/check-in controls to make changes to centrally-stored files but this means you'll be slinging entire copies of your datasets down to client machines on the regular; that may not work well for you. The best answer is PostgreSQL/PostGIS and that's going to take some time and effort. Cost of doing business. ___ QGIS-User mailing list QGIS-User@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only
I access files over a network and haven't really noticed a speed issue, but I use NFS, which is not available on Windows (my computers run Linux) there are other file formats, geopackage is not the only one out there - spatialite also uses SQLite. On 17/03/23 03:08, Árni Geirsson via QGIS-User wrote: I do appreciate the good advice to use DBMS, I am doing that too and understand the advantages. I would never consider using a geopackage if I thought that multiple people would want to edit them at the same time. But that is not the case and that is not my problem. Sometimes, I just want to keep geodata in a file on a network share and run the risk (in my case insignificant) that the file will be corrupted by multi user access. This I can do with shapefiles, but unlike the shapefiles, I have to set the read-only flag on the geopackages stored on the network to get decent rendering speed, without ever wanting to edit the files. I think wanting to use file based storage for geodata in a networked environment is not unreasonable, even if there is some danger of corruption. All file based formats are probably subject to that risk, but I repeat, that issue is not what I am talking about, just the rendering speed of data in a geopackage that is not set to read-only. I suspect that there is no solution and that I will just have to live with this - as I have done for years. It is just a bit annoying. And I am surprised how little it is discussed. Árni ___ QGIS-User mailing list QGIS-User@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only
Hi! If just storing and reading is the scope and not editing, maybe another file format would be suitable. Like https://flatgeobuf.org/. Not tested by me but could be a good alternative. Karl-Magnus Jönsson Från: QGIS-User För Árni Geirsson via QGIS-User Skickat: den 16 mars 2023 15:08 Till: Sadowski Jarosław Kopia: qgis-user@lists.osgeo.org Ämne: Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only I do appreciate the good advice to use DBMS, I am doing that too and understand the advantages. I would never consider using a geopackage if I thought that multiple people would want to edit them at the same time. But that is not the case and that is not my problem. Sometimes, I just want to keep geodata in a file on a network share and run the risk (in my case insignificant) that the file will be corrupted by multi user access. This I can do with shapefiles, but unlike the shapefiles, I have to set the read-only flag on the geopackages stored on the network to get decent rendering speed, without ever wanting to edit the files. I think wanting to use file based storage for geodata in a networked environment is not unreasonable, even if there is some danger of corruption. All file based formats are probably subject to that risk, but I repeat, that issue is not what I am talking about, just the rendering speed of data in a geopackage that is not set to read-only. I suspect that there is no solution and that I will just have to live with this - as I have done for years. It is just a bit annoying. And I am surprised how little it is discussed. Árni On Thu, 16 Mar 2023 at 13:46, Sadowski Jarosław via QGIS-User mailto:qgis-user@lists.osgeo.org>> wrote: +1 Don’t use file formats to edit by multiple users. I was occurring some critical problems, as for example disappearing objects from database or LONG read for first time ☹ Use PostgreSQL or other solutions like: Mergin Maps: Collect, Store and Analyze your Geo-Data Easily<https://merginmaps.com/> GIS Support » GIS.Box (gis--support-pl.translate.goog)<https://gis--support-pl.translate.goog/gis-box/?_x_tr_sl=pl&_x_tr_tl=en&_x_tr_hl=pl&_x_tr_pto=wapp> _ Jarosław Sadowski Kierownik Zespołu ds. Ochrony Środowiska | Biuro Strategii i Planowania, Projektowania i Inżynierii Podprogramu Kolejowego Environmental Protection Team Leader | Railway Subprogramme Strategy & Planning, Design & Engineering Department e: jaroslaw.sadow...@cpk.pl<mailto:jaroslaw.sadow...@cpk.pl> m: +48 532 720 230 From: QGIS-User mailto:qgis-user-boun...@lists.osgeo.org>> On Behalf Of Bo Victor Thomsen via QGIS-User Sent: Thursday, March 16, 2023 2:35 PM To: qgis-user@lists.osgeo.org<mailto:qgis-user@lists.osgeo.org> Subject: Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only UWAGA: Ta wiadomość pochodzi spoza CPK Sp. z o.o. Proszę pomóż zadbać o bezpieczeństwo naszej organizacji. Zastanów się, zanim otworzysz link lub załącznik. When any user on your network access the geopackage layer and (maybe unnecessarily) puts the layer in edit mode, there will be created 2 extra files in the same directory as the gpkg file resides in. And QGIS behaves different regarding both read and write operations when these file are present. This is probably the explanation of the longer reading times, even if nobody actually is editing the layer. When the user stops the editing mode for the layer, the 2 files disappear. You can check if this is the explanation: 1. Open the gpkg layer in read mode on one computer, check the access speed of the same layer on another computer. 2. Set the layer in edit mode on the first computer, check the access speed to the layer on the second computer 3. Revert the edit mode on the first computer, check the access speed to the layer on the second computer. I am guessing, that situations 1 and 3 are fast, while situation 2 is slow. First of all: Never, ever try to implement some kind of multi-user editing on a file based format, where the file resides on a networked drive. It will never, ever work reliably. At some point 2 users will try to edit the same layer at the same time and it will go kaboom (I can read from your mails that you are aware about this). This goes for - probably - every file based format on a network drive. Secondly: What about making the gpkg file read-only at the network share level for most of the users. And only granting write access to the gpkg file for certain users that are instructed in not setting the layer in edit mode unless it's strictly necessary ? The best solution: Install Postgres/PostGIS on your NAS Med venlig hilsen / Best regards Bo Victor Thomsen Den 16-03-2023 kl. 13:49 skrev Árni Geirsson via QGIS-User: Thank you for the various responses. Let me be clear that what I am griping about is not the locking aspect that would allow mul
Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only
You'd only be "living with it" because you choose to use the wrong tools for the work and refuse to use the right ones. In this case, I see the "wrong tools" here as 1) network-shared files for common r/w access 2) the SMB/CIFS protocol in general 3) appliance-type file servers are trash. You can try to make things better by standing up a proper Linux-based file server and using NFS instead of SMB/CIFS but 1) is enough of a problem that you'd only be throwing good work after bad. If it suits your use cases, you might try implementing something like git - which is after a fashion just another networked file-sharing protocol - and use check-out/check-in controls to make changes to centrally-stored files but this means you'll be slinging entire copies of your datasets down to client machines on the regular; that may not work well for you. The best answer is PostgreSQL/PostGIS and that's going to take some time and effort. Cost of doing business. On 3/16/23 10:08 AM, Árni Geirsson via QGIS-User wrote: I do appreciate the good advice to use DBMS, I am doing that too and understand the advantages. I would never consider using a geopackage if I thought that multiple people would want to edit them at the same time. But that is not the case and that is not my problem. Sometimes, I just want to keep geodata in a file on a network share and run the risk (in my case insignificant) that the file will be corrupted by multi user access. This I can do with shapefiles, but unlike the shapefiles, I have to set the read-only flag on the geopackages stored on the network to get decent rendering speed, without ever wanting to edit the files. I think wanting to use file based storage for geodata in a networked environment is not unreasonable, even if there is some danger of corruption. All file based formats are probably subject to that risk, but I repeat, that issue is not what I am talking about, just the rendering speed of data in a geopackage that is not set to read-only. I suspect that there is no solution and that I will just have to live with this - as I have done for years. It is just a bit annoying. And I am surprised how little it is discussed. Árni On Thu, 16 Mar 2023 at 13:46, Sadowski Jarosław via QGIS-User wrote: +1 Don’t use file formats to edit by multiple users. I was occurring some critical problems, as for example disappearing objects from database or LONG read for first time ☹ Use PostgreSQL or other solutions like: Mergin Maps: Collect, Store and Analyze your Geo-Data Easily <https://merginmaps.com/> GIS Support » GIS.Box (gis--support-pl.translate.goog) <https://gis--support-pl.translate.goog/gis-box/?_x_tr_sl=pl&_x_tr_tl=en&_x_tr_hl=pl&_x_tr_pto=wapp> *_* *Jarosław Sadowski* Kierownik Zespołu ds. Ochrony Środowiska | /Biuro Strategii i Planowania, Projektowania i Inżynierii Podprogramu Kolejowego/ /Environmental Protection Team Leader //| Railway Subprogramme Strategy & Planning, Design & Engineering Department/ e: jaroslaw.sadow...@cpk.pl m: +48 532 720 230 *From:*QGIS-User *On Behalf Of *Bo Victor Thomsen via QGIS-User *Sent:* Thursday, March 16, 2023 2:35 PM *To:* qgis-user@lists.osgeo.org *Subject:* Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only UWAGA: Ta wiadomość pochodzi spoza CPK Sp. z o.o. Proszę pomóż zadbać o bezpieczeństwo naszej organizacji. Zastanów się, zanim otworzysz link lub załącznik. When any user on your network access the geopackage layer and (maybe unnecessarily) puts the layer in edit mode, there will be created 2 extra files in the same directory as the gpkg file resides in. And QGIS behaves different regarding /both/ read and write operations when these file are present. This is probably the explanation of the longer reading times, even if nobody actually is editing the layer. When the user stops the editing mode for the layer, the 2 files disappear. You can check if this is the explanation: 1. Open the gpkg layer in read mode on one computer, check the access speed of the same layer on /another/ computer. 2. Set the layer in edit mode on the first computer, check the access speed to the layer on the second computer 3. Revert the edit mode on the first computer, check the access speed to the layer on the second computer. I am guessing, that situations 1 and 3 are fast, while situation 2 is slow. First of all: Never, ever try to implement some kind of multi-user editing on a file based format, where the file resides on a networked drive. It will never, ever work reliably. At some point 2 users will try to edit the same layer at the same time and it will go kaboom (I can read from your mails that you are awa
Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only
Hi Árni, You can try setting the SQLITE_USE_OGR_VFS=YES configuration option, as mentioned at https://github.com/qgis/QGIS/issues/27899. Be sure to read the implications of changing the default (NO) option: https://gdal.org/drivers/vector/sqlite.html#configuration-options You can change the config option in a environment variable or a config file: https://gdal.org/user/configoptions.html#configuration-options Regards, Gabriel El jue, 16 mar 2023 a la(s) 11:08, Árni Geirsson via QGIS-User ( qgis-user@lists.osgeo.org) escribió: > I do appreciate the good advice to use DBMS, I am doing that too and > understand the advantages. I would never consider using a geopackage if I > thought that multiple people would want to edit them at the same time. But > that is not the case and that is not my problem. Sometimes, I just want to > keep geodata in a file on a network share and run the risk (in my case > insignificant) that the file will be corrupted by multi user access. This I > can do with shapefiles, but unlike the shapefiles, I have to set the > read-only flag on the geopackages stored on the network to get decent > rendering speed, without ever wanting to edit the files. I think wanting to > use file based storage for geodata in a networked environment is not > unreasonable, even if there is some danger of corruption. All file based > formats are probably subject to that risk, but I repeat, that issue is not > what I am talking about, just the rendering speed of data in a geopackage > that is not set to read-only. > I suspect that there is no solution and that I will just have to live with > this - as I have done for years. It is just a bit annoying. And I am > surprised how little it is discussed. > > Árni > > > On Thu, 16 Mar 2023 at 13:46, Sadowski Jarosław via QGIS-User < > qgis-user@lists.osgeo.org> wrote: > >> +1 >> >> >> >> Don’t use file formats to edit by multiple users. I was occurring some >> critical problems, as for example disappearing objects from database or >> LONG read for first time ☹ >> >> >> >> Use PostgreSQL or other solutions like: >> >> Mergin Maps: Collect, Store and Analyze your Geo-Data Easily >> <https://merginmaps.com/> >> >> GIS Support » GIS.Box (gis--support-pl.translate.goog) >> <https://gis--support-pl.translate.goog/gis-box/?_x_tr_sl=pl&_x_tr_tl=en&_x_tr_hl=pl&_x_tr_pto=wapp> >> >> >> >> >> *_* >> >> *Jarosław Sadowski* >> Kierownik Zespołu ds. Ochrony Środowiska | *Biuro Strategii i >> Planowania, Projektowania i Inżynierii Podprogramu Kolejowego* >> *Environmental Protection Team Leader **| Railway Subprogramme Strategy >> & Planning, Design & Engineering Department* >> e: jaroslaw.sadow...@cpk.pl >> m: +48 532 720 230 >> >> *From:* QGIS-User *On Behalf Of *Bo >> Victor Thomsen via QGIS-User >> *Sent:* Thursday, March 16, 2023 2:35 PM >> *To:* qgis-user@lists.osgeo.org >> *Subject:* Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not >> read-only >> >> >> >> UWAGA: Ta wiadomość pochodzi spoza CPK Sp. z o.o. Proszę pomóż zadbać o >> bezpieczeństwo naszej organizacji. Zastanów się, zanim otworzysz link lub >> załącznik. >> >> >> >> When any user on your network access the geopackage layer and (maybe >> unnecessarily) puts the layer in edit mode, there will be created 2 extra >> files in the same directory as the gpkg file resides in. And QGIS behaves >> different regarding *both* read and write operations when these file are >> present. This is probably the explanation of the longer reading times, even >> if nobody actually is editing the layer. When the user stops the editing >> mode for the layer, the 2 files disappear. >> >> You can check if this is the explanation: >> >>1. Open the gpkg layer in read mode on one computer, check the access >>speed of the same layer on *another* computer. >>2. Set the layer in edit mode on the first computer, check the access >>speed to the layer on the second computer >>3. Revert the edit mode on the first computer, check the access speed >>to the layer on the second computer. >> >> I am guessing, that situations 1 and 3 are fast, while situation 2 is >> slow. >> >> First of all: Never, ever try to implement some kind of multi-user >> editing on a file based format, where the file resides on a networked >> drive. It will never, ever work reliably. At some point 2 users will try to >> edit the same layer at the same time and it will go kaboo
Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only
I do appreciate the good advice to use DBMS, I am doing that too and understand the advantages. I would never consider using a geopackage if I thought that multiple people would want to edit them at the same time. But that is not the case and that is not my problem. Sometimes, I just want to keep geodata in a file on a network share and run the risk (in my case insignificant) that the file will be corrupted by multi user access. This I can do with shapefiles, but unlike the shapefiles, I have to set the read-only flag on the geopackages stored on the network to get decent rendering speed, without ever wanting to edit the files. I think wanting to use file based storage for geodata in a networked environment is not unreasonable, even if there is some danger of corruption. All file based formats are probably subject to that risk, but I repeat, that issue is not what I am talking about, just the rendering speed of data in a geopackage that is not set to read-only. I suspect that there is no solution and that I will just have to live with this - as I have done for years. It is just a bit annoying. And I am surprised how little it is discussed. Árni On Thu, 16 Mar 2023 at 13:46, Sadowski Jarosław via QGIS-User < qgis-user@lists.osgeo.org> wrote: > +1 > > > > Don’t use file formats to edit by multiple users. I was occurring some > critical problems, as for example disappearing objects from database or > LONG read for first time ☹ > > > > Use PostgreSQL or other solutions like: > > Mergin Maps: Collect, Store and Analyze your Geo-Data Easily > <https://merginmaps.com/> > > GIS Support » GIS.Box (gis--support-pl.translate.goog) > <https://gis--support-pl.translate.goog/gis-box/?_x_tr_sl=pl&_x_tr_tl=en&_x_tr_hl=pl&_x_tr_pto=wapp> > > > > > *_* > > *Jarosław Sadowski* > Kierownik Zespołu ds. Ochrony Środowiska | *Biuro Strategii i Planowania, > Projektowania i Inżynierii Podprogramu Kolejowego* > *Environmental Protection Team Leader **| Railway Subprogramme Strategy & > Planning, Design & Engineering Department* > e: jaroslaw.sadow...@cpk.pl > m: +48 532 720 230 > > *From:* QGIS-User *On Behalf Of *Bo > Victor Thomsen via QGIS-User > *Sent:* Thursday, March 16, 2023 2:35 PM > *To:* qgis-user@lists.osgeo.org > *Subject:* Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not > read-only > > > > UWAGA: Ta wiadomość pochodzi spoza CPK Sp. z o.o. Proszę pomóż zadbać o > bezpieczeństwo naszej organizacji. Zastanów się, zanim otworzysz link lub > załącznik. > > > > When any user on your network access the geopackage layer and (maybe > unnecessarily) puts the layer in edit mode, there will be created 2 extra > files in the same directory as the gpkg file resides in. And QGIS behaves > different regarding *both* read and write operations when these file are > present. This is probably the explanation of the longer reading times, even > if nobody actually is editing the layer. When the user stops the editing > mode for the layer, the 2 files disappear. > > You can check if this is the explanation: > >1. Open the gpkg layer in read mode on one computer, check the access >speed of the same layer on *another* computer. >2. Set the layer in edit mode on the first computer, check the access >speed to the layer on the second computer >3. Revert the edit mode on the first computer, check the access speed >to the layer on the second computer. > > I am guessing, that situations 1 and 3 are fast, while situation 2 is > slow. > > First of all: Never, ever try to implement some kind of multi-user editing > on a file based format, where the file resides on a networked drive. It > will never, ever work reliably. At some point 2 users will try to edit the > same layer at the same time and it will go kaboom (I can read from your > mails that you are aware about this). This goes for - probably - every file > based format on a network drive. > > Secondly: What about making the gpkg file read-only at the network share > level for most of the users. And only granting write access to the gpkg > file for certain users that are instructed in *not* setting the layer in > edit mode unless it's strictly necessary ? > > The best solution: Install Postgres/PostGIS on your NAS > > Med venlig hilsen / Best regards > > > > Bo Victor Thomsen > > Den 16-03-2023 kl. 13:49 skrev Árni Geirsson via QGIS-User: > > Thank you for the various responses. > > Let me be clear that what I am griping about is not the locking aspect > that would allow multiple users to edit without conflict. I fully > understand that the geopackage is not safe for that, nor is the shapefile > and perh
Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only
there is such a system. It is called a client server DBMS. Apart from the fact they are designed to handle multiple users, they can also economise on network traffic by splitting the workload between the client and the server. On 17/03/23 01:33, Sebastian Gutwein via QGIS-User wrote: This is all beyond my expertise but I have also struggled with the effective use of gpkg’s. In my case over google drive. Here is what SQLite (the underlying software for gpkgs) says about using a SQLite database on a network: https://www.sqlite.org/useovernet.html I hope that someday someone implements a system that allows this to work efficiently as gpkgs are better in many respects than shapefiles. Perhaps Geodiff could be part of that solution. ___ QGIS-User mailing list QGIS-User@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-user Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only
+1 Don’t use file formats to edit by multiple users. I was occurring some critical problems, as for example disappearing objects from database or LONG read for first time ☹ Use PostgreSQL or other solutions like: Mergin Maps: Collect, Store and Analyze your Geo-Data Easily<https://merginmaps.com/> GIS Support » GIS.Box (gis--support-pl.translate.goog)<https://gis--support-pl.translate.goog/gis-box/?_x_tr_sl=pl&_x_tr_tl=en&_x_tr_hl=pl&_x_tr_pto=wapp> _ Jarosław Sadowski Kierownik Zespołu ds. Ochrony Środowiska | Biuro Strategii i Planowania, Projektowania i Inżynierii Podprogramu Kolejowego Environmental Protection Team Leader | Railway Subprogramme Strategy & Planning, Design & Engineering Department e: jaroslaw.sadow...@cpk.pl<mailto:jaroslaw.sadow...@cpk.pl> m: +48 532 720 230 From: QGIS-User On Behalf Of Bo Victor Thomsen via QGIS-User Sent: Thursday, March 16, 2023 2:35 PM To: qgis-user@lists.osgeo.org Subject: Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only UWAGA: Ta wiadomość pochodzi spoza CPK Sp. z o.o. Proszę pomóż zadbać o bezpieczeństwo naszej organizacji. Zastanów się, zanim otworzysz link lub załącznik. When any user on your network access the geopackage layer and (maybe unnecessarily) puts the layer in edit mode, there will be created 2 extra files in the same directory as the gpkg file resides in. And QGIS behaves different regarding both read and write operations when these file are present. This is probably the explanation of the longer reading times, even if nobody actually is editing the layer. When the user stops the editing mode for the layer, the 2 files disappear. You can check if this is the explanation: 1. Open the gpkg layer in read mode on one computer, check the access speed of the same layer on another computer. 2. Set the layer in edit mode on the first computer, check the access speed to the layer on the second computer 3. Revert the edit mode on the first computer, check the access speed to the layer on the second computer. I am guessing, that situations 1 and 3 are fast, while situation 2 is slow. First of all: Never, ever try to implement some kind of multi-user editing on a file based format, where the file resides on a networked drive. It will never, ever work reliably. At some point 2 users will try to edit the same layer at the same time and it will go kaboom (I can read from your mails that you are aware about this). This goes for - probably - every file based format on a network drive. Secondly: What about making the gpkg file read-only at the network share level for most of the users. And only granting write access to the gpkg file for certain users that are instructed in not setting the layer in edit mode unless it's strictly necessary ? The best solution: Install Postgres/PostGIS on your NAS Med venlig hilsen / Best regards Bo Victor Thomsen Den 16-03-2023 kl. 13:49 skrev Árni Geirsson via QGIS-User: Thank you for the various responses. Let me be clear that what I am griping about is not the locking aspect that would allow multiple users to edit without conflict. I fully understand that the geopackage is not safe for that, nor is the shapefile and perhaps also the file geodatabase. In my case, the likelihood of two people wanting to edit the same geopackage is negligible, so I take my chances. My only gripe is the rendering speed of larger geopackages on a shared network, if they are not set specifically to read-only. That is not a problem with the shapefile and I think probably not with a file geodatabase. I am a long time user of geopackages in a networked environment and I will continue to use them - they are great - there is just this problem of rendering speed over a network. Árni On Thu, 16 Mar 2023 at 12:33, Sebastian Gutwein mailto:b...@rdgland.com>> wrote: This is all beyond my expertise but I have also struggled with the effective use of gpkg’s. In my case over google drive. Here is what SQLite (the underlying software for gpkgs) says about using a SQLite database on a network: https://www.sqlite.org/useovernet.html<https://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.sqlite.org%2Fuseovernet.html=05%7C01%7Cjaroslaw.sadowski%40cpk.pl%7Cd767a39352fb48744fbc08db26235086%7Cfa798250ca0b4a1bb47381cff4a1752b%7C1%7C0%7C638145705353555137%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=gF5jBExKrp2Hlks%2FQEHefiiG0FJFhqAG8fJ0VxBs4Kc%3D=0> I hope that someday someone implements a system that allows this to work efficiently as gpkgs are better in many respects than shapefiles. Perhaps Geodiff could be part of that solution. https://github.com/MerginMaps/geodiff<https://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FMerginMaps%2Fgeodiff=05%7C01%7Cjaroslaw.sadowski%40cpk.pl%7Cd767a39352fb48
Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only
you, among others, in the e-mail correspondence, is Centralny
Port Komunikacyjny Sp. z o. o. based in Warsaw. The personal
data is processed by us in accordance with the provisions of
the General Data Protection Regulation (GDPR), for further
information please read the Privacy Policy tab and the
Information Clause on the www.cpk.pl
<http://www.cpk.pl/>website.
The content of this message and its attachments constitute
the Business Secret within the meaning of the Act of 16 April
1993 on combating unfair competition. If you received this
message by mistake, contact the sender of the message
immediately and delete its content
*From:*QGIS-User *On
Behalf Of *Árni Geirsson via QGIS-User
*Sent:* Thursday, March 16, 2023 10:18 AM
*To:* jhubbsl...@att.net
*Cc:* qgis-user@lists.osgeo.org
*Subject:* [EXTERNAL] Re: [Qgis-user] Geopackage slow on NAS
if not read-only
UWAGA: Ta wiadomość pochodzi spoza CPK Sp. z o.o. Proszę
pomóż zadbać o bezpieczeństwo naszej organizacji. Zastanów
się, zanim otworzysz link lub załącznik.
Yes, as far as I know, the NAS unit uses SMB as the file
sharing protocol. I used another NAS from QNAP before this
one, also using SMB and with the same problem. I thought
pretty much all of the Linux based NAS units were using SMB
and if that is the problem, it should be widespread, but I
don't see any signs of that. Is SMB a problem for geopackage?
I did a quick test in QGIS: A dataset of 178.000 line
features is rendered in about 1 second from a read only
geopackage. When I remove the read only flag, it is rendered
in about 5 seconds.
If I store the geopackage on the local hard drive, the
problem disappears, read-write or read-only does not matter.
I have had suspicions about SMB being part of the problem but
I don't know enough about file access deep down in the
operating system to understand it.
Árni Geirsson
On Thu, 16 Mar 2023 at 01:45, jhubbslist--- via QGIS-User
mailto:qgis-user@lists.osgeo.org>> wrote:
Árni -
Are you using SMB/CIFS to access this NAS, and are you
using wifi or Ethernet to connect to it?
- Jeff
On 3/15/23 3:30 PM, Árni Geirsson via QGIS-User wrote:
Hello all QGIS and geopackage users.
I store my geopackages on a Synology RackStation NAS
unit, like all other documents that are kept on a
shared drive in the office. For larger datasets, the
rendering is very slow, unless I open the properties
dialog for the file in Windows and check the read
only box. After that, the features are rendered
blazingly fast. Nothing else is changed to see the
dramatic difference in the rendering speed. Luckily,
I don't need to edit many of the larger datasets,
such as road networks and elevation contours and
the geopackage can be kept read only. Shapefiles are
not affected.
What explains this and does anyone know how to solve
the problem?
Do other users experience this?
Árni Geirsson
___
QGIS-User mailing list
QGIS-User@lists.osgeo.org
List info:https://lists.osgeo.org/mailman/listinfo/qgis-user
<https://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fqgis-user=05%7C01%7Cjaroslaw.sadowski%40cpk.pl%7C11269f199d644f13364608db25ff69c5%7Cfa798250ca0b4a1bb47381cff4a1752b%7C1%7C0%7C638145551176051605%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=4NfOOZrB2k%2B7Q3V0QHNXIvEOTYHFWp4D10C1MzYTTQQ%3D=0>
Unsubscribe:
https://lists.osgeo.org/mailman/listinfo/qgis-user
<https://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fqgis-user=05%7C01%7Cjaroslaw.sadowski%40cpk.pl%7C11269f199d644f13364608db25ff69c5%7Cfa798250ca0b4a1bb47381cff4a1752b%7C1%7C0%7C638145551176051605%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=4NfOOZrB2k%2B7Q3V0QHNXIvEOTYHFWp4D10C1MzYTTQQ%3D=0>
___
QGIS-User mailing list
QGIS-User@lists.osgeo.org <mailto:QGIS-User@lists.osgeo.org>
List info:
https://lists.osgeo.org/mailman/listinfo/qgis-user
<https://eur06.safelinks.protection.outlook.com/?u
Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only
geopackages is not a realistic option
for me, but I could get a different kind of NAS unit, if
that helps, what kind then? What amazes me is how little
I see this discussed. There was a message in this thread
this morning from Thomas Struller, but I am not sure it
is about the same root problem, maybe Thomas can elaborate.
Should this perhaps be discussed in another forum, closer
to the development of geopackage/sqlite?
Árni Geirsson
On Thu, 16 Mar 2023 at 09:52, Sadowski Jarosław
wrote:
Long story short: gpkg is bad idea for network drives
as SMB/NAS etc
Sources:
Write-Ahead Logging (sqlite.org)
<https://www.sqlite.org/wal.html#advantages>
writing gpkg and sqlite on samba shares fails · Issue
#628 · r-spatial/sf · GitHub
<https://github.com/r-spatial/sf/issues/628>
*_*
*Jarosław Sadowski*
Kierownik Zespołu ds. Ochrony Środowiska |/Biuro
Strategii i Planowania, Projektowania i Inżynierii
Podprogramu Kolejowego/
/Environmental Protection Team Leader //| Railway
Subprogramme Strategy & Planning, Design &
Engineering Department/
e: jaroslaw.sadow...@cpk.pl
m: +48 532 720 230
Centralny Port Komunikacyjny Sp. z o.o. z siedzibą w
Warszawie, Aleje Jerozolimskie 142B, 02-305 Warszawa
<https://www.google.com/maps/search/Aleje%0D%0AJerozolimskie+142B,+02-305+Warszawa?entry=gmail=g>;
nr KRS 759991, Sąd Rejonowy dla m.st
<http://m.st>. Warszawy, XII Wydział Gospodarczy
Krajowego Rejestru Sądowego; NIP 701-08-94-497; REGON
381918620; kapitał zakładowy 1.277.500.000,00 zł
Administratorem danych osobowych przekazanych przez
Panią/Pana m.in. w korespondencji mailowej jest
Centralny Port Komunikacyjny Sp. z o.o. z siedzibą w
Warszawie. Przetwarzamy dane osobowe zgodnie z
przepisami ogólnego rozporządzenia o ochronie danych
(RODO), więcej informacji na ten temat znajduje się w
zakładce Polityka Prywatności oraz w Klauzuli
informacyjnej na stronie internetowej www.cpk.pl
<http://www.cpk.pl/>.
Treści zawarte w niniejszej wiadomości i załącznikach
do niej stanowią Tajemnicę Przedsiębiorstwa w
rozumieniu ustawy z dnia 16 kwietnia 1993 r. o
zwalczaniu nieuczciwej konkurencji. Jeśli otrzymałeś
tę wiadomość przez pomyłkę, bezzwłocznie skontaktuj
się z nadawcą wiadomości oraz usuń jej treść.
Centralny Port Komunikacyjny Sp. z o.o. with
headquarters in Warsaw, Aleje Jerozolimskie 142B,
02-305 Warsaw
<https://www.google.com/maps/search/Warsaw,+Aleje%0D%0AJerozolimskie+142B,+02-305+Warsaw?entry=gmail=g>;
KRS No. 759991, District Court for the Capital
City of Warsaw, 12th Commercial Department of the
National Court Register; NIP 701-08-94-497; REGON
381918620; share capital of PLN 1.277.500.000,00.
The personal data controller of the personal data
provided by you, among others, in the e-mail
correspondence, is Centralny Port Komunikacyjny Sp. z
o. o. based in Warsaw. The personal data is processed
by us in accordance with the provisions of the
General Data Protection Regulation (GDPR), for
further information please read the Privacy Policy
tab and the Information Clause on the www.cpk.pl
<http://www.cpk.pl/>website.
The content of this message and its attachments
constitute the Business Secret within the meaning of
the Act of 16 April 1993 on combating unfair
competition. If you received this message by mistake,
contact the sender of the message immediately and
delete its content
*From:*QGIS-User
*On Behalf Of *Árni Geirsson via QGIS-User
*Sent:* Thursday, March 16, 2023 10:18 AM
*To:* jhubbsl...@att.net
*Cc:* qgis-user@lists.osgeo.org
*Subject:* [EXTERNAL] Re: [Qgis-user] Geopackage slow
on NAS if not read-only
UWAGA: Ta wiadomość pochodzi spoza CPK Sp. z o.o.
Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only
>>>> e: jaroslaw.sadow...@cpk.pl >>>> m: +48 532 720 230 >>>> >>>> Centralny Port Komunikacyjny Sp. z o.o. z siedzibą w Warszawie, Aleje >>>> Jerozolimskie 142B, 02-305 Warszawa >>>> <https://www.google.com/maps/search/Aleje%0D%0AJerozolimskie+142B,+02-305+Warszawa?entry=gmail=g>; >>>> nr KRS 759991, Sąd Rejonowy dla m.st. Warszawy, XII Wydział >>>> Gospodarczy Krajowego Rejestru Sądowego; NIP 701-08-94-497; REGON >>>> 381918620; kapitał zakładowy 1.277.500.000,00 zł >>>> Administratorem danych osobowych przekazanych przez Panią/Pana m.in. w >>>> korespondencji mailowej jest Centralny Port Komunikacyjny Sp. z o.o. z >>>> siedzibą w Warszawie. Przetwarzamy dane osobowe zgodnie z przepisami >>>> ogólnego rozporządzenia o ochronie danych (RODO), więcej informacji na ten >>>> temat znajduje się w zakładce Polityka Prywatności oraz w Klauzuli >>>> informacyjnej na stronie internetowej www.cpk.pl. >>>> Treści zawarte w niniejszej wiadomości i załącznikach do niej stanowią >>>> Tajemnicę Przedsiębiorstwa w rozumieniu ustawy z dnia 16 kwietnia 1993 r. o >>>> zwalczaniu nieuczciwej konkurencji. Jeśli otrzymałeś tę wiadomość przez >>>> pomyłkę, bezzwłocznie skontaktuj się z nadawcą wiadomości oraz usuń jej >>>> treść. >>>> Centralny Port Komunikacyjny Sp. z o.o. with headquarters in Warsaw, >>>> Aleje Jerozolimskie 142B, 02-305 Warsaw >>>> <https://www.google.com/maps/search/Warsaw,+Aleje%0D%0AJerozolimskie+142B,+02-305+Warsaw?entry=gmail=g>; >>>> KRS No. 759991, District Court for the Capital City of Warsaw, 12th >>>> Commercial Department of the National Court Register; NIP 701-08-94-497; >>>> REGON 381918620; share capital of PLN 1.277.500.000,00. >>>> The personal data controller of the personal data provided by you, >>>> among others, in the e-mail correspondence, is Centralny Port Komunikacyjny >>>> Sp. z o. o. based in Warsaw. The personal data is processed by us in >>>> accordance with the provisions of the General Data Protection Regulation >>>> (GDPR), for further information please read the Privacy Policy tab and the >>>> Information Clause on the www.cpk.pl website. >>>> The content of this message and its attachments constitute the Business >>>> Secret within the meaning of the Act of 16 April 1993 on combating unfair >>>> competition. If you received this message by mistake, contact the sender of >>>> the message immediately and delete its content >>>> >>>> *From:* QGIS-User *On Behalf Of *Árni >>>> Geirsson via QGIS-User >>>> *Sent:* Thursday, March 16, 2023 10:18 AM >>>> *To:* jhubbsl...@att.net >>>> *Cc:* qgis-user@lists.osgeo.org >>>> *Subject:* [EXTERNAL] Re: [Qgis-user] Geopackage slow on NAS if not >>>> read-only >>>> >>>> >>>> >>>> UWAGA: Ta wiadomość pochodzi spoza CPK Sp. z o.o. Proszę pomóż zadbać o >>>> bezpieczeństwo naszej organizacji. Zastanów się, zanim otworzysz link >>>> lub załącznik. >>>> >>>> >>>> >>>> Yes, as far as I know, the NAS unit uses SMB as the file sharing >>>> protocol. I used another NAS from QNAP before this one, also using SMB and >>>> with the same problem. I thought pretty much all of the Linux based NAS >>>> units were using SMB and if that is the problem, it should be widespread, >>>> but I don't see any signs of that. Is SMB a problem for geopackage? >>>> >>>> I did a quick test in QGIS: A dataset of 178.000 line features is >>>> rendered in about 1 second from a read only geopackage. When I remove the >>>> read only flag, it is rendered in about 5 seconds. >>>> >>>> If I store the geopackage on the local hard drive, the problem >>>> disappears, read-write or read-only does not matter. >>>> >>>> I have had suspicions about SMB being part of the problem but I don't >>>> know enough about file access deep down in the operating system to >>>> understand it. >>>> >>>> >>>> >>>> Árni Geirsson >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Thu, 16 Mar 2023 at 01:45, jhubbslist--- via QGIS-User < >>>> qgis-user@lists.osgeo.org> wrote: >
Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only
t;> zwalczaniu nieuczciwej konkurencji. Jeśli otrzymałeś tę wiadomość przez >>> pomyłkę, bezzwłocznie skontaktuj się z nadawcą wiadomości oraz usuń jej >>> treść. >>> Centralny Port Komunikacyjny Sp. z o.o. with headquarters in Warsaw, >>> Aleje Jerozolimskie 142B, 02-305 Warsaw >>> <https://www.google.com/maps/search/Warsaw,+Aleje%0D%0AJerozolimskie+142B,+02-305+Warsaw?entry=gmail=g>; >>> KRS No. 759991, District Court for the Capital City of Warsaw, 12th >>> Commercial Department of the National Court Register; NIP 701-08-94-497; >>> REGON 381918620; share capital of PLN 1.277.500.000,00. >>> The personal data controller of the personal data provided by you, among >>> others, in the e-mail correspondence, is Centralny Port Komunikacyjny Sp. z >>> o. o. based in Warsaw. The personal data is processed by us in accordance >>> with the provisions of the General Data Protection Regulation (GDPR), for >>> further information please read the Privacy Policy tab and the Information >>> Clause on the www.cpk.pl website. >>> The content of this message and its attachments constitute the Business >>> Secret within the meaning of the Act of 16 April 1993 on combating unfair >>> competition. If you received this message by mistake, contact the sender of >>> the message immediately and delete its content >>> >>> *From:* QGIS-User *On Behalf Of *Árni >>> Geirsson via QGIS-User >>> *Sent:* Thursday, March 16, 2023 10:18 AM >>> *To:* jhubbsl...@att.net >>> *Cc:* qgis-user@lists.osgeo.org >>> *Subject:* [EXTERNAL] Re: [Qgis-user] Geopackage slow on NAS if not >>> read-only >>> >>> >>> >>> UWAGA: Ta wiadomość pochodzi spoza CPK Sp. z o.o. Proszę pomóż zadbać o >>> bezpieczeństwo naszej organizacji. Zastanów się, zanim otworzysz link >>> lub załącznik. >>> >>> >>> >>> Yes, as far as I know, the NAS unit uses SMB as the file sharing >>> protocol. I used another NAS from QNAP before this one, also using SMB and >>> with the same problem. I thought pretty much all of the Linux based NAS >>> units were using SMB and if that is the problem, it should be widespread, >>> but I don't see any signs of that. Is SMB a problem for geopackage? >>> >>> I did a quick test in QGIS: A dataset of 178.000 line features is >>> rendered in about 1 second from a read only geopackage. When I remove the >>> read only flag, it is rendered in about 5 seconds. >>> >>> If I store the geopackage on the local hard drive, the problem >>> disappears, read-write or read-only does not matter. >>> >>> I have had suspicions about SMB being part of the problem but I don't >>> know enough about file access deep down in the operating system to >>> understand it. >>> >>> >>> >>> Árni Geirsson >>> >>> >>> >>> >>> >>> >>> >>> On Thu, 16 Mar 2023 at 01:45, jhubbslist--- via QGIS-User < >>> qgis-user@lists.osgeo.org> wrote: >>> >>> Árni - >>> >>> >>> >>> Are you using SMB/CIFS to access this NAS, and are you using wifi or >>> Ethernet to connect to it? >>> >>> >>> >>> - Jeff >>> >>> >>> >>> On 3/15/23 3:30 PM, Árni Geirsson via QGIS-User wrote: >>> >>> Hello all QGIS and geopackage users. >>> >>> I store my geopackages on a Synology RackStation NAS unit, like all >>> other documents that are kept on a shared drive in the office. For larger >>> datasets, the rendering is very slow, unless I open the properties dialog >>> for the file in Windows and check the read only box. After that, the >>> features are rendered blazingly fast. Nothing else is changed to see the >>> dramatic difference in the rendering speed. Luckily, I don't need to edit >>> many of the larger datasets, such as road networks and elevation contours >>> and the geopackage can be kept read only. Shapefiles are not affected. >>> >>> What explains this and does anyone know how to solve the problem? >>> >>> Do other users experience this? >>> >>> >>> >>> Árni Geirsson >>> >>> >>> >>> ___ >>> >>> QGIS-User mailing list >>> >>> QGIS-User@lists.osgeo.org >>> >>> List info: https:/
Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only
mość przez >>> pomyłkę, bezzwłocznie skontaktuj się z nadawcą wiadomości oraz usuń jej >>> treść. >>> Centralny Port Komunikacyjny Sp. z o.o. with headquarters in Warsaw, >>> Aleje Jerozolimskie 142B, 02-305 Warsaw; KRS No. 759991, District Court >>> for the Capital City of Warsaw, 12th Commercial Department of the National >>> Court Register; NIP 701-08-94-497; REGON 381918620; share capital of PLN >>> 1.277.500.000,00. >>> The personal data controller of the personal data provided by you, among >>> others, in the e-mail correspondence, is Centralny Port Komunikacyjny Sp. z >>> o. o. based in Warsaw. The personal data is processed by us in accordance >>> with the provisions of the General Data Protection Regulation (GDPR), for >>> further information please read the Privacy Policy tab and the Information >>> Clause on the www.cpk.pl website. >>> The content of this message and its attachments constitute the Business >>> Secret within the meaning of the Act of 16 April 1993 on combating unfair >>> competition. If you received this message by mistake, contact the sender of >>> the message immediately and delete its content >>> >>> *From:* QGIS-User *On Behalf Of *Árni >>> Geirsson via QGIS-User >>> *Sent:* Thursday, March 16, 2023 10:18 AM >>> *To:* jhubbsl...@att.net >>> *Cc:* qgis-user@lists.osgeo.org >>> *Subject:* [EXTERNAL] Re: [Qgis-user] Geopackage slow on NAS if not >>> read-only >>> >>> >>> >>> UWAGA: Ta wiadomość pochodzi spoza CPK Sp. z o.o. Proszę pomóż zadbać o >>> bezpieczeństwo naszej organizacji. Zastanów się, zanim otworzysz link >>> lub załącznik. >>> >>> >>> >>> Yes, as far as I know, the NAS unit uses SMB as the file sharing >>> protocol. I used another NAS from QNAP before this one, also using SMB and >>> with the same problem. I thought pretty much all of the Linux based NAS >>> units were using SMB and if that is the problem, it should be widespread, >>> but I don't see any signs of that. Is SMB a problem for geopackage? >>> >>> I did a quick test in QGIS: A dataset of 178.000 line features is >>> rendered in about 1 second from a read only geopackage. When I remove the >>> read only flag, it is rendered in about 5 seconds. >>> >>> If I store the geopackage on the local hard drive, the problem >>> disappears, read-write or read-only does not matter. >>> >>> I have had suspicions about SMB being part of the problem but I don't >>> know enough about file access deep down in the operating system to >>> understand it. >>> >>> >>> >>> Árni Geirsson >>> >>> >>> >>> >>> >>> >>> >>> On Thu, 16 Mar 2023 at 01:45, jhubbslist--- via QGIS-User < >>> qgis-user@lists.osgeo.org> wrote: >>> >>> Árni - >>> >>> >>> >>> Are you using SMB/CIFS to access this NAS, and are you using wifi or >>> Ethernet to connect to it? >>> >>> >>> >>> - Jeff >>> >>> >>> >>> On 3/15/23 3:30 PM, Árni Geirsson via QGIS-User wrote: >>> >>> Hello all QGIS and geopackage users. >>> >>> I store my geopackages on a Synology RackStation NAS unit, like all >>> other documents that are kept on a shared drive in the office. For larger >>> datasets, the rendering is very slow, unless I open the properties dialog >>> for the file in Windows and check the read only box. After that, the >>> features are rendered blazingly fast. Nothing else is changed to see the >>> dramatic difference in the rendering speed. Luckily, I don't need to edit >>> many of the larger datasets, such as road networks and elevation contours >>> and the geopackage can be kept read only. Shapefiles are not affected. >>> >>> What explains this and does anyone know how to solve the problem? >>> >>> Do other users experience this? >>> >>> >>> >>> Árni Geirsson >>> >>> >>> >>> ___ >>> >>> QGIS-User mailing list >>> >>> QGIS-User@lists.osgeo.org >>> >>> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user >>> <https://eur06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.osgeo.org%2Fmailman%2Flistinfo%2Fqgis-user=05%7C01%7Cjarosla
Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only
Hi Jorge I understand what you are pointing at and I use databases such as Postgres/PostGIS also with good results. The thing is that working with data in files sometimes has advantages and that is certainly how shapefiles have been used. The geopackage has been suggested as a replacement for the shapefile in the context of regular QGIS usage without any caveat saying that geopackages only replace the storage and transfer role of shapefiles and that geopackages should not be used for editing in a shared environment, as is perfectly possible with shapefiles and widely practiced. Not all users have access to database systems such as Postgres. I'm just looking for some clarity on best practices for the common scenario of working with QGIS using file based data in a network environment. Árni On Thu, 16 Mar 2023 at 11:47, Jorge Gustavo Rocha via QGIS-User < qgis-user@lists.osgeo.org> wrote: > Hi, > > For data storage and manipulation databases are suitable. Files are not. > > Geopackages are wonderful to transfer data between systems or to archive > an entire project (snapshot of data, styles and the project itself). > > Regards, > > Jorge > On 16/03/23 11:30, Árni Geirsson via QGIS-User wrote: > > Thank you Jarosław. Isn't it strange that this was discussed 5 years ago > and SMB file sharing is very common? Would a linux based NAS be able to use > another protocol? What are my options for file based data sharing in QGIS? > Abandoning geopackages is not a realistic option for me, but I could get a > different kind of NAS unit, if that helps, what kind then? What amazes me > is how little I see this discussed. There was a message in this thread this > morning from Thomas Struller, but I am not sure it is about the same root > problem, maybe Thomas can elaborate. > Should this perhaps be discussed in another forum, closer to the > development of geopackage/sqlite? > > Árni Geirsson > > On Thu, 16 Mar 2023 at 09:52, Sadowski Jarosław > wrote: > >> Long story short: gpkg is bad idea for network drives as SMB/NAS etc >> >> >> >> Sources: >> Write-Ahead Logging (sqlite.org) >> <https://www.sqlite.org/wal.html#advantages> >> >> writing gpkg and sqlite on samba shares fails · Issue #628 · r-spatial/sf >> · GitHub <https://github.com/r-spatial/sf/issues/628> >> >> >> >> >> >> *_* >> >> *Jarosław Sadowski* >> Kierownik Zespołu ds. Ochrony Środowiska | *Biuro Strategii i >> Planowania, Projektowania i Inżynierii Podprogramu Kolejowego* >> *Environmental Protection Team Leader **| Railway Subprogramme Strategy >> & Planning, Design & Engineering Department* >> e: jaroslaw.sadow...@cpk.pl >> m: +48 532 720 230 >> >> Centralny Port Komunikacyjny Sp. z o.o. z siedzibą w Warszawie, Aleje >> Jerozolimskie 142B, 02-305 Warszawa; nr KRS 759991, Sąd Rejonowy dla >> m.st. Warszawy, XII Wydział Gospodarczy Krajowego Rejestru Sądowego; NIP >> 701-08-94-497; REGON 381918620; kapitał zakładowy 1.277.500.000,00 zł >> Administratorem danych osobowych przekazanych przez Panią/Pana m.in. w >> korespondencji mailowej jest Centralny Port Komunikacyjny Sp. z o.o. z >> siedzibą w Warszawie. Przetwarzamy dane osobowe zgodnie z przepisami >> ogólnego rozporządzenia o ochronie danych (RODO), więcej informacji na ten >> temat znajduje się w zakładce Polityka Prywatności oraz w Klauzuli >> informacyjnej na stronie internetowej www.cpk.pl. >> Treści zawarte w niniejszej wiadomości i załącznikach do niej stanowią >> Tajemnicę Przedsiębiorstwa w rozumieniu ustawy z dnia 16 kwietnia 1993 r. o >> zwalczaniu nieuczciwej konkurencji. Jeśli otrzymałeś tę wiadomość przez >> pomyłkę, bezzwłocznie skontaktuj się z nadawcą wiadomości oraz usuń jej >> treść. >> Centralny Port Komunikacyjny Sp. z o.o. with headquarters in Warsaw, >> Aleje Jerozolimskie 142B, 02-305 Warsaw; KRS No. 759991, District Court >> for the Capital City of Warsaw, 12th Commercial Department of the National >> Court Register; NIP 701-08-94-497; REGON 381918620; share capital of PLN >> 1.277.500.000,00. >> The personal data controller of the personal data provided by you, among >> others, in the e-mail correspondence, is Centralny Port Komunikacyjny Sp. z >> o. o. based in Warsaw. The personal data is processed by us in accordance >> with the provisions of the General Data Protection Regulation (GDPR), for >> further information please read the Privacy Policy tab and the Information >> Clause on the www.cpk.pl website. >> The content of this message and its attachments constitute the Business >> Secret within the
Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only
Hi,
For data storage and manipulation databases are suitable. Files are not.
Geopackages are wonderful to transfer data between systems or to archive
an entire project (snapshot of data, styles and the project itself).
Regards,
Jorge
On 16/03/23 11:30, Árni Geirsson via QGIS-User wrote:
Thank you Jarosław. Isn't it strange that this was discussed 5 years
ago and SMB file sharing is very common? Would a linux based NAS be
able to use another protocol? What are my options for file based data
sharing in QGIS? Abandoning geopackages is not a realistic option for
me, but I could get a different kind of NAS unit, if that helps, what
kind then? What amazes me is how little I see this discussed. There
was a message in this thread this morning from Thomas Struller, but I
am not sure it is about the same root problem, maybe Thomas can
elaborate.
Should this perhaps be discussed in another forum, closer to the
development of geopackage/sqlite?
Árni Geirsson
On Thu, 16 Mar 2023 at 09:52, Sadowski Jarosław
wrote:
Long story short: gpkg is bad idea for network drives as SMB/NAS etc
Sources:
Write-Ahead Logging (sqlite.org)
<https://www.sqlite.org/wal.html#advantages>
writing gpkg and sqlite on samba shares fails · Issue #628 ·
r-spatial/sf · GitHub <https://github.com/r-spatial/sf/issues/628>
*_*
*Jarosław Sadowski*
Kierownik Zespołu ds. Ochrony Środowiska |/Biuro Strategii i
Planowania, Projektowania i Inżynierii Podprogramu Kolejowego/
/Environmental Protection Team Leader //| Railway Subprogramme
Strategy & Planning, Design & Engineering Department/
e: jaroslaw.sadow...@cpk.pl
m: +48 532 720 230
Centralny Port Komunikacyjny Sp. z o.o. z siedzibą w Warszawie,
Aleje Jerozolimskie 142B, 02-305 Warszawa; nr KRS 759991, Sąd
Rejonowy dla m.st <http://m.st>. Warszawy, XII Wydział Gospodarczy
Krajowego Rejestru Sądowego; NIP 701-08-94-497; REGON 381918620;
kapitał zakładowy 1.277.500.000,00 zł
Administratorem danych osobowych przekazanych przez Panią/Pana
m.in. w korespondencji mailowej jest Centralny Port Komunikacyjny
Sp. z o.o. z siedzibą w Warszawie. Przetwarzamy dane osobowe
zgodnie z przepisami ogólnego rozporządzenia o ochronie danych
(RODO), więcej informacji na ten temat znajduje się w zakładce
Polityka Prywatności oraz w Klauzuli informacyjnej na stronie
internetowej www.cpk.pl <http://www.cpk.pl/>.
Treści zawarte w niniejszej wiadomości i załącznikach do niej
stanowią Tajemnicę Przedsiębiorstwa w rozumieniu ustawy z dnia 16
kwietnia 1993 r. o zwalczaniu nieuczciwej konkurencji. Jeśli
otrzymałeś tę wiadomość przez pomyłkę, bezzwłocznie skontaktuj się
z nadawcą wiadomości oraz usuń jej treść.
Centralny Port Komunikacyjny Sp. z o.o. with headquarters in
Warsaw, Aleje Jerozolimskie 142B, 02-305 Warsaw; KRS No.
759991, District Court for the Capital City of Warsaw, 12th
Commercial Department of the National Court Register; NIP
701-08-94-497; REGON 381918620; share capital of PLN 1.277.500.000,00.
The personal data controller of the personal data provided by you,
among others, in the e-mail correspondence, is Centralny Port
Komunikacyjny Sp. z o. o. based in Warsaw. The personal data is
processed by us in accordance with the provisions of the General
Data Protection Regulation (GDPR), for further information please
read the Privacy Policy tab and the Information Clause on the
www.cpk.pl <http://www.cpk.pl/>website.
The content of this message and its attachments constitute the
Business Secret within the meaning of the Act of 16 April 1993 on
combating unfair competition. If you received this message by
mistake, contact the sender of the message immediately and delete
its content
*From:*QGIS-User *On Behalf Of
*Árni Geirsson via QGIS-User
*Sent:* Thursday, March 16, 2023 10:18 AM
*To:* jhubbsl...@att.net
*Cc:* qgis-user@lists.osgeo.org
*Subject:* [EXTERNAL] Re: [Qgis-user] Geopackage slow on NAS if
not read-only
UWAGA: Ta wiadomość pochodzi spoza CPK Sp. z o.o. Proszę pomóż
zadbać o bezpieczeństwo naszej organizacji. Zastanów się, zanim
otworzysz link lub załącznik.
Yes, as far as I know, the NAS unit uses SMB as the file sharing
protocol. I used another NAS from QNAP before this one, also using
SMB and with the same problem. I thought pretty much all of the
Linux based NAS units were using SMB and if that is the problem,
it should be widespread, but I don't see any signs of that. Is SMB
a problem for geopackage?
I did a quick test in QGIS: A dataset of 178.000 line features is
rendered in about 1 second from a read only geopackage. When I
remove the read only flag, it is rendered in about 5 seconds.
If I store the geopackage on the local
Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only
Thank you Jarosław. Isn't it strange that this was discussed 5 years ago and SMB file sharing is very common? Would a linux based NAS be able to use another protocol? What are my options for file based data sharing in QGIS? Abandoning geopackages is not a realistic option for me, but I could get a different kind of NAS unit, if that helps, what kind then? What amazes me is how little I see this discussed. There was a message in this thread this morning from Thomas Struller, but I am not sure it is about the same root problem, maybe Thomas can elaborate. Should this perhaps be discussed in another forum, closer to the development of geopackage/sqlite? Árni Geirsson On Thu, 16 Mar 2023 at 09:52, Sadowski Jarosław wrote: > Long story short: gpkg is bad idea for network drives as SMB/NAS etc > > > > Sources: > Write-Ahead Logging (sqlite.org) > <https://www.sqlite.org/wal.html#advantages> > > writing gpkg and sqlite on samba shares fails · Issue #628 · r-spatial/sf > · GitHub <https://github.com/r-spatial/sf/issues/628> > > > > > > > *_* > > *Jarosław Sadowski* > Kierownik Zespołu ds. Ochrony Środowiska | *Biuro Strategii i Planowania, > Projektowania i Inżynierii Podprogramu Kolejowego* > *Environmental Protection Team Leader **| Railway Subprogramme Strategy & > Planning, Design & Engineering Department* > e: jaroslaw.sadow...@cpk.pl > m: +48 532 720 230 > > Centralny Port Komunikacyjny Sp. z o.o. z siedzibą w Warszawie, Aleje > Jerozolimskie 142B, 02-305 Warszawa; nr KRS 759991, Sąd Rejonowy dla > m.st. Warszawy, XII Wydział Gospodarczy Krajowego Rejestru Sądowego; NIP > 701-08-94-497; REGON 381918620; kapitał zakładowy 1.277.500.000,00 zł > Administratorem danych osobowych przekazanych przez Panią/Pana m.in. w > korespondencji mailowej jest Centralny Port Komunikacyjny Sp. z o.o. z > siedzibą w Warszawie. Przetwarzamy dane osobowe zgodnie z przepisami > ogólnego rozporządzenia o ochronie danych (RODO), więcej informacji na ten > temat znajduje się w zakładce Polityka Prywatności oraz w Klauzuli > informacyjnej na stronie internetowej www.cpk.pl. > Treści zawarte w niniejszej wiadomości i załącznikach do niej stanowią > Tajemnicę Przedsiębiorstwa w rozumieniu ustawy z dnia 16 kwietnia 1993 r. o > zwalczaniu nieuczciwej konkurencji. Jeśli otrzymałeś tę wiadomość przez > pomyłkę, bezzwłocznie skontaktuj się z nadawcą wiadomości oraz usuń jej > treść. > Centralny Port Komunikacyjny Sp. z o.o. with headquarters in Warsaw, Aleje > Jerozolimskie 142B, 02-305 Warsaw; KRS No. 759991, District Court for > the Capital City of Warsaw, 12th Commercial Department of the National > Court Register; NIP 701-08-94-497; REGON 381918620; share capital of PLN > 1.277.500.000,00. > The personal data controller of the personal data provided by you, among > others, in the e-mail correspondence, is Centralny Port Komunikacyjny Sp. z > o. o. based in Warsaw. The personal data is processed by us in accordance > with the provisions of the General Data Protection Regulation (GDPR), for > further information please read the Privacy Policy tab and the Information > Clause on the www.cpk.pl website. > The content of this message and its attachments constitute the Business > Secret within the meaning of the Act of 16 April 1993 on combating unfair > competition. If you received this message by mistake, contact the sender of > the message immediately and delete its content > > *From:* QGIS-User *On Behalf Of *Árni > Geirsson via QGIS-User > *Sent:* Thursday, March 16, 2023 10:18 AM > *To:* jhubbsl...@att.net > *Cc:* qgis-user@lists.osgeo.org > *Subject:* [EXTERNAL] Re: [Qgis-user] Geopackage slow on NAS if not > read-only > > > > UWAGA: Ta wiadomość pochodzi spoza CPK Sp. z o.o. Proszę pomóż zadbać o > bezpieczeństwo naszej organizacji. Zastanów się, zanim otworzysz link lub > załącznik. > > > > Yes, as far as I know, the NAS unit uses SMB as the file sharing protocol. > I used another NAS from QNAP before this one, also using SMB and with the > same problem. I thought pretty much all of the Linux based NAS units were > using SMB and if that is the problem, it should be widespread, but I don't > see any signs of that. Is SMB a problem for geopackage? > > I did a quick test in QGIS: A dataset of 178.000 line features is rendered > in about 1 second from a read only geopackage. When I remove the read only > flag, it is rendered in about 5 seconds. > > If I store the geopackage on the local hard drive, the problem disappears, > read-write or read-only does not matter. > > I have had suspicions about SMB being part of the problem but I don't know > enough about file access deep down in the operating system to understan
Re: [Qgis-user] [EXTERNAL] Re: Geopackage slow on NAS if not read-only
Long story short: gpkg is bad idea for network drives as SMB/NAS etc Sources: Write-Ahead Logging (sqlite.org)<https://www.sqlite.org/wal.html#advantages> writing gpkg and sqlite on samba shares fails * Issue #628 * r-spatial/sf * GitHub<https://github.com/r-spatial/sf/issues/628> _ Jarosław Sadowski Kierownik Zespołu ds. Ochrony Środowiska | Biuro Strategii i Planowania, Projektowania i Inżynierii Podprogramu Kolejowego Environmental Protection Team Leader | Railway Subprogramme Strategy & Planning, Design & Engineering Department e: jaroslaw.sadow...@cpk.pl<mailto:jaroslaw.sadow...@cpk.pl> m: +48 532 720 230 [cid:transparency_ce4012c8-87e7-4198-a48f-d42a38680681.png] Centralny Port Komunikacyjny Sp. z o.o. z siedzibą w Warszawie, Aleje Jerozolimskie 142B, 02-305 Warszawa; nr KRS 759991, Sąd Rejonowy dla m.st. Warszawy, XII Wydział Gospodarczy Krajowego Rejestru Sądowego; NIP 701-08-94-497; REGON 381918620; kapitał zakładowy 1.277.500.000,00 zł Administratorem danych osobowych przekazanych przez Panią/Pana m.in. w korespondencji mailowej jest Centralny Port Komunikacyjny Sp. z o.o. z siedzibą w Warszawie. Przetwarzamy dane osobowe zgodnie z przepisami ogólnego rozporządzenia o ochronie danych (RODO), więcej informacji na ten temat znajduje się w zakładce Polityka Prywatności oraz w Klauzuli informacyjnej na stronie internetowej www.cpk.pl<http://www.cpk.pl/>. Treści zawarte w niniejszej wiadomości i załącznikach do niej stanowią Tajemnicę Przedsiębiorstwa w rozumieniu ustawy z dnia 16 kwietnia 1993 r. o zwalczaniu nieuczciwej konkurencji. Jeśli otrzymałeś tę wiadomość przez pomyłkę, bezzwłocznie skontaktuj się z nadawcą wiadomości oraz usuń jej treść. Centralny Port Komunikacyjny Sp. z o.o. with headquarters in Warsaw, Aleje Jerozolimskie 142B, 02-305 Warsaw; KRS No. 759991, District Court for the Capital City of Warsaw, 12th Commercial Department of the National Court Register; NIP 701-08-94-497; REGON 381918620; share capital of PLN 1.277.500.000,00. The personal data controller of the personal data provided by you, among others, in the e-mail correspondence, is Centralny Port Komunikacyjny Sp. z o. o. based in Warsaw. The personal data is processed by us in accordance with the provisions of the General Data Protection Regulation (GDPR), for further information please read the Privacy Policy tab and the Information Clause on the www.cpk.pl<http://www.cpk.pl/> website. The content of this message and its attachments constitute the Business Secret within the meaning of the Act of 16 April 1993 on combating unfair competition. If you received this message by mistake, contact the sender of the message immediately and delete its content From: QGIS-User On Behalf Of Árni Geirsson via QGIS-User Sent: Thursday, March 16, 2023 10:18 AM To: jhubbsl...@att.net Cc: qgis-user@lists.osgeo.org Subject: [EXTERNAL] Re: [Qgis-user] Geopackage slow on NAS if not read-only UWAGA: Ta wiadomość pochodzi spoza CPK Sp. z o.o. Proszę pomóż zadbać o bezpieczeństwo naszej organizacji. Zastanów się, zanim otworzysz link lub załącznik. Yes, as far as I know, the NAS unit uses SMB as the file sharing protocol. I used another NAS from QNAP before this one, also using SMB and with the same problem. I thought pretty much all of the Linux based NAS units were using SMB and if that is the problem, it should be widespread, but I don't see any signs of that. Is SMB a problem for geopackage? I did a quick test in QGIS: A dataset of 178.000 line features is rendered in about 1 second from a read only geopackage. When I remove the read only flag, it is rendered in about 5 seconds. If I store the geopackage on the local hard drive, the problem disappears, read-write or read-only does not matter. I have had suspicions about SMB being part of the problem but I don't know enough about file access deep down in the operating system to understand it. Árni Geirsson On Thu, 16 Mar 2023 at 01:45, jhubbslist--- via QGIS-User mailto:qgis-user@lists.osgeo.org>> wrote: Árni - Are you using SMB/CIFS to access this NAS, and are you using wifi or Ethernet to connect to it? - Jeff On 3/15/23 3:30 PM, Árni Geirsson via QGIS-User wrote: Hello all QGIS and geopackage users. I store my geopackages on a Synology RackStation NAS unit, like all other documents that are kept on a shared drive in the office. For larger datasets, the rendering is very slow, unless I open the properties dialog for the file in Windows and check the read only box. After that, the features are rendered blazingly fast. Nothing else is changed to see the dramatic difference in the rendering speed. Luckily, I don't need to edit many of the larger datasets, such as road networks and elevation contours and the geopackage can be kept read only. Shapefiles are not affected. What explains this and does anyone know how to solve the problem? Do
