Hi On Wed, Jan 27, 2021 at 11:38 PM Nyall Dawson <[email protected]> wrote:
> On Thu, 28 Jan 2021 at 00:32, C Hamilton <[email protected]> wrote: > > > > Tim, > > > > 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. > > > > 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. > > 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... > 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. Regards Tim > > Nyall > > > > > > 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. > > > > 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. > > > > 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. > > > > 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. > > > > 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. > > > > 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. > > > > I await the QGIS developers decision on this. > > > > Thanks! > > > >>> 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. > >> > >> > >> Regard > >> > >> Tim > >> > >> _______________________________________________ > >> Qgis-user mailing list > >> [email protected] > >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user > >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user > > > > _______________________________________________ > > Qgis-user mailing list > > [email protected] > > List info: https://lists.osgeo.org/mailman/listinfo/qgis-user > > Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user > -- ------------------------------------------------------------------------------------------ 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
