[Qgis-user] [QGIS-Developer] New QGIS Date/Time Tools Plugin

[Nyall Dawson]

On Fri, 29 Jan 2021 at 01:13, C Hamilton <adenaculture at 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
>>
>>