[QGIS-Developer] [Qgis-user] New QGIS Date/Time Tools Plugin

[Tim Sutton]

Hi

On Wed, Jan 27, 2021 at 11:38 PM Nyall Dawson <nyall.dawson at gmail.com>
wrote:

> On Thu, 28 Jan 2021 at 00:32, C Hamilton <adenaculture at gmail.com> 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
> >> Qgis-user at lists.osgeo.org
> >> List info: https://lists.osgeo.org/mailman/listinfo/qgis-user
> >> Unsubscribe: https://lists.osgeo.org/mailman/listinfo/qgis-user
> >
> > _______________________________________________
> > Qgis-user mailing list
> > Qgis-user at lists.osgeo.org
> > 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
-------------------------------------------------------------------------------------------
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20210128/692a64a3/attachment-0001.html>