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 <[email protected]> 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 <[email protected]> > 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 -------------------------------------------------------------------------------------------
_______________________________________________ QGIS-Developer mailing list [email protected] List info: https://lists.osgeo.org/mailman/listinfo/qgis-developer Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-developer
