[QGIS-Developer] timezonefinder discussions

[Tim Sutton]

Thanks Calvin (and apologies for calling your Chris last time I wrote!). It
is so nice when discussions get synthesised at the end.

Feel free to contact me offlist if you want to still go the route of
publishing your larger-than-normally-allowed plugin on the plugin repo.

Regards

Tim

On Wed, Feb 10, 2021 at 3:33 PM C Hamilton <adenaculture at gmail.com> wrote:

> First I want to thank everyone for their input in this discussion, but it
> did get off track. Originally, I asked whether my Date/Time Tools plugin
> <https://github.com/NationalSecurityAgency/qgis-datetimetools-plugin> I
> created for our users could be added to plugins.qgis.org. It includes the
> timezonefinder library which is ~42 Mb in size and exceeds the maximum size
> of a plugin for inclusion in the QGIS plugin repo.
>
> Note that I have a very good reason for making sure that every one of my
> plugins are self contained primarily because my users don't manage their
> machines and consequently cannot install extra python libraries which is
> what timezonefinder is so it has to be included with the plugin.
>
> It was suggested to not use timezonefinder, but just use the time zone
> polygon layer. That way I wouldn't need to bundle an extra python library.
> I wanted to test if this would be as fast as timezonefinder. Here is where
> the conversation got side tracked because I created the 10,000 random point
> layer for the purpose of testing how quickly "single point" lookups could
> be done using timezonefinder vs. some QGIS point in polygon look up. It was
> NOT about finding the time zones for the 10,000 points all at once. The
> 10,000 points were just a data source for timing single point lookups so
> although "Join Attributes by Location" does a great job of identifying all
> 10,000 points at once that was NOT what I was trying to accomplish and I
> don't think that would be the proper solution for looking up single points,
> such as displaying the time zone in an info box as the mouse moves over the
> QGIS canvas. On each motion event, a single point lookup is done.
>
> 1. Currently timezonefinder works great for my users. Although the plugin
> is ~50Mb if I were to removed timezonefinder library and just use the time
> zone polygon layer it would increase to ~100Mb. This could be an extra
> download, but I like to make it easy for my users and just include it.
>
> 2. Using the time zone gpkg polygon layer is slightly more accurate, but
> not by much.
>
> 3. So far I have not found that single point lookups in the time zone
> polygon layer to be faster than the timezonefinder lookup. This may be
> because I am currently developing on a Windows AWS instance and the point
> in polygon lookups may be slow because the time zone gpkg layer resides
> somewhere on the file system.
>
> 4. There is merit in using the time zone polygon gpkg layer. There are
> some other algorithms that could be implemented that would benefit from it.
> Right now I only have a Date, Time, and Time Zone conversion tool and
> either method would work fine for this.
>
> 5. I still have a lot to think about including implement some astronomical
> algorithms of the sun and moon. The plugin already implements some sun
> related information.
>
> I really appreciate everyone's comments. They have given me some new
> ideas. For my users, timezonefinder does what we need, but it is probably
> not the best method for the QGIS community especially with the plugin size
> limitation.
>
> I really don't want to take up any more of your time especially you QGIS
> developers who have so many other duties. We can end the discussion here.
> My priority will always be for my users, but I will try to make the plugin
> useful to the community as well as long as it doesn't take me too much more
> time to satisfy the plugin size restriction.
>
> Thanks for all you do,
>
> Calvin
>
> On Wed, Feb 10, 2021 at 3:48 AM Richard Duivenvoorde <rdmailings at duif.net>
> wrote:
>
>> Hi Chris,
>>
>> I see all this discussions on the list (going round and round....).
>>
>> Wasn't the conclusion that:
>> 1) you just use your first version (which included that data, and was a
>> little big....)
>> 2) put it on plugins.qgis.org (via Tim, as uploading it would probably
>> fail because of size)
>> 3) we keep the 'max size' of plugins small, to not get overloaded with
>> super heavy plugins?
>>
>> To not taking up too much energy from you (or all mail thread responders)
>> :-)
>>
>> Or do *I* miss some information?
>>
>> Regards,
>>
>> Richard Duivenvoorde
>>
>>

-- 
------------------------------------------------------------------------------------------
​

Tim Sutton
Visit http://kartoza.com to find out about open source:
 * Desktop GIS programming services
 * Geospatial web development
* GIS Training
* Consulting Services
Tim is a member of the QGIS Project Steering Committee
-------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20210210/e4467534/attachment-0001.html>