<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif;font-size:small">Hi<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Jan 27, 2021 at 11:38 PM Nyall Dawson <<a href="mailto:nyall.dawson@gmail.com">nyall.dawson@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Thu, 28 Jan 2021 at 00:32, C Hamilton <<a href="mailto:adenaculture@gmail.com" target="_blank">adenaculture@gmail.com</a>> wrote:<br>
><br>
> Tim,<br>
><br>
> I understand the position you are in and I really struggled in even wanting to put in the time to develop this plugin knowing that there would probably be a problem getting it accepted by the QGIS developers because of its size, but our users have a very real need for this capability which is why I consented to develop it at all.<br>
><br>
> In order to deal with locating time zones based on a coordinate there is simply no way to get around the size of the python library required if accuracy of the results is desired. That feature alone requires 42Mb. I struggle to convince our GIS analysts to use QGIS over ArcGIS and so I try to provide solutions that work better than those in ArcGIS, but if there is any sort of complication that makes it more difficult for one of the analysts to get the resources they need for QGIS then I have lost the battle. This includes having them pip install additional python libraries because most of them do not have system admin privileges.<br>
<br>
Given that the size of the python library is almost entirely the size<br>
of the timezone boundaries themselves, have you considered:<br>
- avoiding the library entirely, and insteading using a standard<br>
shapefile/gpkg/... of the boundaries and using QGIS vector layer<br>
methods to determine the timezone for a point<br>
- deferring the download of the boundary spatial data, so that it's<br>
not supplied with the plugin but instead the plugin automatically<br>
downloads it on first launch?<br>
<br>
This would avoid the need for the large size plugin, allowing it to be<br>
supplied via the standard QGIS repo while still providing its full<br>
functionality...<br></blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small" class="gmail_default">So Chris, try Nyall's approach and if that does not work for you, pop a note here and we will see if we can make a local exception without generally increasing the size limit for plugins.<br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small" class="gmail_default">Regards</div><div style="font-family:arial,helvetica,sans-serif;font-size:small" class="gmail_default"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small" class="gmail_default">Tim</div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Nyall<br>
<br>
<br>
><br>
> I can easily set up the ability for users to point to a separate repo that houses this plugin, but once again that is an additional complication. Every once in a while I find some QGIS repo of plugins that are not a part of the official QGIS repo and I think that it is too bad that they are probably not used much outside of the organization who hosts them. Unless a plugin exists on the official QGIS repo it will not be discoverable and will not likely be used by many.<br>
><br>
> I think the plans I have with this plugin will make it very useful to the QGIS community, but if it cannot be a part of the QGIS repo it will not be of much use to the community. Our users will make use of it because we will provide it to them. I would like to swap out the astral library for the Skyfield library with the JPL ephemeris data to provide more precise sun and moon calculations, but that adds an additional ~20Mb.<br>
><br>
> I would love it if you would provide timezonefinder and Skyfield libraries by default with the QGIS distribution, but that increases the size of the QGIS download. When you are dealing with time zones and astronomical calculations, there is no way in getting around the plugin size to get the best accuracy available. I personally am not interested in providing tools with less accuracy.<br>
><br>
> I don't know how important it will be for the QIGS community to have these tools available, but I know that there will be a number of users who have been looking for these capabilities in QGIS and will be valuable to them. Right now I have coded only one of a number of tools that I have planned, but part of my plans will be determined by the QGIS acceptance of a larger plugin. I think my other QGIS plugins I have provided including "Lat Lon Tools", "Shape Tools" & "KML Tools" shows how useful my plugins have been.<br>
><br>
> If there is something I am missing or some other way around this let me know, but keep in mind I hold to two fundamental principals with my plugins. 1) They are as accurate at possible. 2) They are self contained meaning that OUR users don't need to install any software to run them. The functionality in Date/Time tools is simply going to take up space and there is no way around it that I can see. I think your "unwritten expectation" of small plugins prevents some capabilities from being introduced, but I also agree that in most instances plugins should be kept small. What I am trying to accomplish simply does not come small.<br>
><br>
> Let me know if you want me to just provide the capabilities for our users alone or to expand it for use by the QGIS community.<br>
><br>
> I await the QGIS developers decision on this.<br>
><br>
> Thanks!<br>
><br>
>>> Personally I would be more on the -1 on upping the limit for plugins - currently at 10mb I think - since large plugins will consume more space on our plugins server and our user's bandwidth. There is an unwritten expectation that plugins should be small and quick to fetch. If others feel strongly with a contrary opinion, contact me offlist and I will help you get it published without generally changing the limit.<br>
>><br>
>><br>
>> Regard<br>
>><br>
>> Tim<br>
>><br>
>> _______________________________________________<br>
>> Qgis-user mailing list<br>
>> <a href="mailto:Qgis-user@lists.osgeo.org" target="_blank">Qgis-user@lists.osgeo.org</a><br>
>> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-user" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-user</a><br>
>> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-user" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-user</a><br>
><br>
> _______________________________________________<br>
> Qgis-user mailing list<br>
> <a href="mailto:Qgis-user@lists.osgeo.org" target="_blank">Qgis-user@lists.osgeo.org</a><br>
> List info: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-user" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-user</a><br>
> Unsubscribe: <a href="https://lists.osgeo.org/mailman/listinfo/qgis-user" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/qgis-user</a><br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div style="text-align:center">------------------------------------------------------------------------------------------</div><div style="text-align:center"><div style="color:rgb(0,0,0);font-family:arial,helvetica,sans-serif;font-size:small;display:inline"></div><img src="https://mail.google.com/mail/u/0/?ui=2&ik=7ebbf93252&view=fimg&th=15a9e43c0bbf93ca&attid=0.1&disp=emb&realattid=9436e64174762963_0.1.1&attbid=ANGjdJ-WL_J24nvBiYidJ0V0xpdsYqRwswi5nq5oywcJEHC7twYVMrxG0y-GNPu_ahJthV8ktXwYuHoVm5DI2FrRAtPzelTRHrsE2wweR9uu8wT-zz2hNRqFwi4SorQ&sz=s0-l75-ft&ats=1488721675176&rm=15a9e43c0bbf93ca&atsh=1" style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px;"><br></div><div style="text-align:center">Tim Sutton</div><div style="text-align:center"><span style="text-align:start">Visit </span><a href="http://kartoza.com/" style="text-align:start" target="_blank">http://kartoza.com</a><span style="text-align:start"> to find out about open source:</span><br style="text-align:start"><span style="text-align:start"> * Desktop GIS programming services</span><br style="text-align:start"><span style="text-align:start"> * Geospatial web development</span></div><div style="text-align:center"><span style="text-align:start">* GIS Training</span></div><div style="text-align:center"><span style="text-align:start">* Consulting Services</span></div><div style="text-align:center"><div style="text-align:center"></div><div style="text-align:start"><div style="text-align:center">Tim is a member of the QGIS Project Steering Committee</div><div style="text-align:center">-------------------------------------------------------------------------------------------</div></div></div></div></div></div></div></div>