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

[Groene Bij]

Hi Calvin,

 

Could you somehow send me a copy of the 10.000 random point layer and the gpkg with the time zones? I would like to try some things, and see if I can come up with some suggestions. I could send you an upload link where you can upload those files to me, if needed.

 

And I am also trying to understand the issue at stake here. You keep referring to ArcGIS. Does ArcGIS has a similar tool incorporated In its software, including the data?

 

And is it necessary to use this tool offline? If so, a database / data file is needed anyway. Than the question is, should it be part of the tool, or should you be able to download the data when needed (or better, beforehand). Benefit of downloading the data separately could be more up to date time zone information.

 

Kind regards,

Jeroen Hovens

 

 

Van: Qgis-user <qgis-user-bounces at lists.osgeo.org> Namens C Hamilton
Verzonden: dinsdag 2 februari 2021 19:40
Aan: Nyall Dawson <nyall.dawson at gmail.com>
CC: QGIS Users <qgis-user at lists.osgeo.org>; Tim Sutton <tim at kartoza.com>; qgis-developer <qgis-developer at lists.osgeo.org>
Onderwerp: Re: [Qgis-user] [QGIS-Developer] New QGIS Date/Time Tools Plugin

 

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-user/attachments/20210202/56f20b7a/attachment.html>