[Qgis-user] Best practice, database vs WFS

Thu Jan 7 04:03:12 PST 2021

great reports in this thread... would make sense to have a best practices
page where to store these reports? nothing complex, just nabble links to
significant thread or posts. Kind of QGIS practice digest :)

Luigi Pirelli

**************************************************************************************************
* LinkedIn: https://www.linkedin.com/in/luigipirelli
* Stackexchange: http://gis.stackexchange.com/users/19667/luigi-pirelli
* GitHub: https://github.com/luipir
* Book: Mastering QGIS3 - 3rd Edition
<https://www.packtpub.com/eu/application-development/mastering-geospatial-development-qgis-3x-third-edition>
* Hire a team: http://www.qcooperative.net
**************************************************************************************************

On Thu, 7 Jan 2021 at 12:49, Bo Victor Thomsen <bo.victor.thomsen at gmail.com>
wrote:

> As a former (Q)GIS administrator for a Danish municipality with:
>
>    - Ca. 100 QGIS users, some experienced and some total newbies
>
>    - Several hundred different spatial data layers in both MS-SQLServer,
>    PostgreSQL and some file based formats.
>
>    - Most of the layers read-only but a significant number of layers
>    editable.
>
> I'll suggest:
>
>    - Don't use WFS for local connections. The added layer of complexity
>    will make the complete system much slower, more unstable and more difficult
>    to administer.
>
>    - Use .qlr files to present the individual layers from the databases
>    for users with symbology and  without them having to use the database
>    connection tabs in the Data Manager.
>
>    - You can save all the different .qlr files in a common network based
>    directory that can be accessed by all users. And make this directory a
>    "favourite" directory in the QGIS Data Manager. This will make data access
>    easy and uniform for every type of data.
>
>    - You can group the .qlr files in logical groups using a directory
>    structure under the main directory. And give the qlr files some easily
>    understood names.
>
>    - Use the database access systems to control the individual user
>    access rights.
>
>    - If you're in a Windows domain based system with windows pc's and
>    postgres servers running on windows, take a look at the SSPI access method.
>    This will give you a "Integrated security" like access to Postgres.
>
>
> Med venlig hilsen / Kind regards
>
> Bo Victor Thomsen
>
> Den 06-01-2021 kl. 16:48 skrev Paul Wittle:
>
> Hi Alessandro,
>
> I guess the key is ease of data discovery. So if all your geodata is on one database then it is all easy enough but if you have multiple database types / instances then you are relying a lot on users being able to find the right database / instance and then having potentially different login mechanisms for each database.
>
> This is why the idea of WFS seems appealing because we can authenticate at access to the WFS server using a single method; expose all the accessible datasets in a single list and in theory potentially employ greater consistency to the method of updates.
>
> We have found that the SQL issued by each database driver can vary in terms of the SQL optimisation because each one is developed independently of others (i.e. the Oracle data access is not necessary developed with much reference to the Postgres or SQL database data access clients). Whilst fundamentally the SQL statements are still in effect translated into the appropriate SQL for each database type the original statement should in theory be more consistent?
>
> In terms of speed; I suspect you are definitely correct hence my asking the question really.
>
> The comments above are really to simply flesh out the question as to whether or not using a database is really simpler though.
>
> That said; we may also use something like a custom plugin or GeoNetwork as a data discovery tool which is another way of helping users add the right layer without needing to know which database it comes from.
>
> I hope that clarifies the question a little better?
>
> Cheers,
> Paul
>
> -----Original Message-----
> From: Alessandro Pasotti <apasotti at gmail.com> <apasotti at gmail.com>
> Sent: 06 January 2021 15:11
> To: Paul Wittle <P.Wittle at dorsetcc.gov.uk> <P.Wittle at dorsetcc.gov.uk>
> Cc: qgis-user at lists.osgeo.org
> Subject: Re: [Qgis-user] Best practice, database vs WFS
>
> Hi Paul,
>
> if you want to share geodata within your organization on a private network a database is the best solution: faster and simpler. The constraint is that you will need an application (like QGIS) to access your data..
>
> WFS is a web service standard for interoperability, it is ideal for sharing data on the internet over HTTP, there is no need for a particular application to use the service: any HTTP client is able to do that.
>
> Regards
>
>
> On Wed, Jan 6, 2021 at 3:43 PM Paul Wittle <paul.wittle at dorsetcouncil.gov.uk> <paul.wittle at dorsetcouncil.gov.uk> wrote:
>
> Hi,
>
>
>
> As I’m sure is clear from the number of posts I’ve done of late we are currently looking at how we use QGIS within our business. I thought I’d ask a question here to see if others are considering it as I can’t find too much chat online about it but I wondered if perhaps there should be some.
>
>
>
> We have concluded that in theory the WFS and WFS-T protocols are an OGC standard (https://www.ogc.org/standards/wfs) and that using an OGC compliant server they can be used to front various data source formats; i.e. Postgres, Oracle, SQL Server etc. In theory that means that if you use WFS and WFS-T in QGIS it should mean that user experience becomes more consistent for the people using those layers in QGIS.
>
>
>
> That all sounds great, but I can’t seem to even get my WFS to load correctly in QGIS at present and it doesn’t seem to be something that is recommended online. Given that both WFS and direct database access both return full details (vector geometries and attributes) to QGIS; would you expect performance of WFS to be similar or significantly slower?
>
>
>
> Is the use of OGC compliant WFS something that you personally feel is something we should be aspiring to use more widely at the local / network level in QGIS or do you favour just loading directly from databases?
>
>
>
> I’m honestly very interested to hear what others think on this as theoretically you would think the creation of an OGC standard would have this sort of aspiration but I’m increasingly concluding that this kind of use of WFS is very limited. It seems to me that the most common use case is just for occasional layers where you need to work with others over the internet.
>
>
>
> To ensure we are talking about the same thing; I’m thinking that the access to WFS in this context would be locally within your own network or device as clearly going over the internet will add a significant overhead and potential for delay.
>
>
>
> Feel free to message me back directly or message the group if you think it is a worthwhile discussion but as I say I’d love to hear what others think.
>
>
>
> Cheers,
>
> Paul
>
>
>
>
>
> This e-mail and any files transmitted with it are intended solely for
> the use of the individual or entity to whom they are addressed. It may
> contain unclassified but sensitive or protectively marked material 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
> traffic may be subject to recording and/or monitoring in accordance
> with relevant legislation. Any views expressed in this message are
> those of the individual sender, except where the sender specifies and
> with authority, states them to be the views of Dorset Council. Dorset
> Council does not accept service of documents by fax or other
> electronic means. Virus checking: Whilst all reasonable steps have
> been taken to ensure that this electronic communication and its
> attachments whether encoded, encrypted or otherwise supplied are free
> from computer viruses, Dorset Council accepts no liability in respect
> of any loss, cost, damage or expense suffered as a result of accessing
> this message or any of its attachments. For information on how Dorset
> Council processes your information, please seewww.dorsetcouncil.gov.uk/416433
> _______________________________________________
> Qgis-user mailing listQgis-user at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
>
> --
> Alessandro Pasotti
> QCooperative:  www.qcooperative.net
> ItOpen:   www.itopen.it
> This e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed. It may contain unclassified but sensitive or protectively marked material 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 traffic may be subject to recording and/or monitoring in accordance with relevant legislation. Any views expressed in this message are those of the individual sender, except where the sender specifies and with authority, states them to be the views of Dorset Council. Dorset Council does not accept service of documents by fax or other electronic means. Virus checking: Whilst all reasonable steps have been taken to ensure that this electronic communication and its attachments whether encoded, encrypted or otherwise supplied are free from computer viruses, Dorset Council accepts no liability in respect of any loss, cost, damage or expense suffered as a result of accessing this message or any of its attachments. For information on how Dorset Council processes your information, please see www.dorsetcouncil.gov.uk/416433
> _______________________________________________
> Qgis-user mailing listQgis-user at 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 at lists.osgeo.org
> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20210107/056355d2/attachment.html>