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

[C Hamilton]

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 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.

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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-user/attachments/20210128/3e0ed9f9/attachment.html>