<div dir="ltr"><div>Tim,</div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I await the QGIS developers decision on this.</div><div><br></div><div>Thanks!</div><div><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Regard</div><div dir="auto"><br></div><div dir="auto">Tim</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"></blockquote></div></div></div>
_______________________________________________<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></div>