[QGIS-Developer] [Qgis-user] New QGIS Date/Time Tools Plugin
C Hamilton
adenaculture at gmail.com
Tue Feb 2 10:40:23 PST 2021
I created a layer of 10,000 random points. Using timezonefinder to look up
each point took 44 seconds. I tried using *Vector->Geoprocessing
Tools->Intersection...* to find the time zones for each of the points and
it took over 4 minutes.
Is there a better way to locate which polygon a point is in? 4 minutes is
not good. Perhaps the intersection algorithm is not the way to go, but I am
not sure what is. I can't imagine that iterating through each point and
then iterating through each polygon until an intersection match is found is
going to be overlay efficient, but I will try it. Is there a better way?
Thanks,
Calvin
>
> > I wonder what the difference in time would be to use a gpkg and QGIS
> point in polygon look up vs timezonefinder lookup. Will it be faster or
> slower? I'm not sure without testing. What are your thoughts? I would
> choose the faster of the two.
>
> I'd certainly hope a dedicated GIS application can do this faster than
> a random Python library :D
>
> > I just converted the timezone data to a gpkg and its size is 102Mb. The
> data size for timezonefinder using the same data set is 49Mb. The
> optimization in timezonefinder can produce a maximum error of 1cm at the
> equator as they use 32 bit ints for the data. It might actually be better
> to use the gpkg file, but it is double in size. I will investigate using
> the gpkg data.
>
> You may want to try a shapefile too, just in case...!
>
> Nyall
>
>
> >
> > It seems to me that if a plugin requires a certain dataset to function
> then that data should be included with it and not require an additional
> download, but I understand the issues that this could cause so I am not
> sure of the best way forward. For our use it is definitely better to
> include the data with the plugin.
> >
> > I guess what I would like you to take from this conversation is that
> some users have a completely different environment and face different
> challenges then what you do when it comes to dealing with software. I wish
> that it was easier for me to get QGIS acceptance in our workforce but
> ArcGIS still rules.
> >
> > Thanks for your ideas and all of the hard work that you do to keep QGIS
> moving forward.
> >
> > I wish you all the very best!
> >
> > Calvin
> >
> >> 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...
> >>
> >> Nyall
> >>
> >>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/qgis-developer/attachments/20210202/6f4e0926/attachment-0001.html>
More information about the QGIS-Developer
mailing list