On Fri, 29 Jan 2021 at 01:13, C Hamilton <adenacult...@gmail.com> wrote: > > Nyall, > > What you mention has merit, but I was not kidding about trying to keep a > plugin self contained for government use. To set up automatic downloading on > our networks would require PKI authentication and that opens up another can > of worms. I know how to deal with PKI because I already maintain plugins that > use authentication. It would be easier for our users to have them download a > data pack and have some manual installation process, but it is even easier if > the data is already a part of the plugin. The other option would be to > produce two different versions of the plugin. One for government use and the > other for community use, but my sponsor would probably frown on that and not > want me to use my time to maintain the community version. > > The author of timezonefinder has done a number of optimizations to provide > fast lookups. See > > https://timezonefinder.readthedocs.io/en/latest/3_about.html > > I wonder what the difference in time would be to use a gpkg and QGIS point in > polygon look up vs timezonefinder lookup. Will it be faster or slower? I'm > not sure without testing. What are your thoughts? I would choose the faster > of the two.
I'd certainly hope a dedicated GIS application can do this faster than a random Python library :D > I just converted the timezone data to a gpkg and its size is 102Mb. The data > size for timezonefinder using the same data set is 49Mb. The optimization in > timezonefinder can produce a maximum error of 1cm at the equator as they use > 32 bit ints for the data. It might actually be better to use the gpkg file, > but it is double in size. I will investigate using the gpkg data. You may want to try a shapefile too, just in case...! Nyall > > It seems to me that if a plugin requires a certain dataset to function then > that data should be included with it and not require an additional download, > but I understand the issues that this could cause so I am not sure of the > best way forward. For our use it is definitely better to include the data > with the plugin. > > I guess what I would like you to take from this conversation is that some > users have a completely different environment and face different challenges > then what you do when it comes to dealing with software. I wish that it was > easier for me to get QGIS acceptance in our workforce but ArcGIS still rules. > > Thanks for your ideas and all of the hard work that you do to keep QGIS > moving forward. > > I wish you all the very best! > > Calvin > >> Given that the size of the python library is almost entirely the size >> of the timezone boundaries themselves, have you considered: >> - avoiding the library entirely, and insteading using a standard >> shapefile/gpkg/... of the boundaries and using QGIS vector layer >> methods to determine the timezone for a point >> - deferring the download of the boundary spatial data, so that it's >> not supplied with the plugin but instead the plugin automatically >> downloads it on first launch? >> >> This would avoid the need for the large size plugin, allowing it to be >> supplied via the standard QGIS repo while still providing its full >> functionality... >> >> Nyall >> >> _______________________________________________ QGIS-Developer mailing list QGIS-Developer@lists.osgeo.org List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
