<div dir="ltr"><div>I created a layer of 10,000 random points. Using timezonefinder to look up each point took 44 seconds. I tried using <b>Vector->Geoprocessing Tools->Intersection...</b> to find the time zones for each of the points and it took over 4 minutes. </div><div><br></div><div>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?</div><div><br></div><div>Thanks,</div><div><br></div><div>Calvin</div><br><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"><br><br>
> 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.<br>
<br>
I'd certainly hope a dedicated GIS application can do this faster than<br>
a random Python library :D<br>
<br>
> 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.<br>
<br>
You may want to try a shapefile too, just in case...!<br>
<br>
Nyall<br>
<br>
<br>
><br>
> 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.<br>
><br>
> 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.<br>
><br>
> Thanks for your ideas and all of the hard work that you do to keep QGIS moving forward.<br>
><br>
> I wish you all the very best!<br>
><br>
> Calvin<br>
><br>
>> Given that the size of the python library is almost entirely the size<br>
>> of the timezone boundaries themselves, have you considered:<br>
>> - avoiding the library entirely, and insteading using a standard<br>
>> shapefile/gpkg/... of the boundaries and using QGIS vector layer<br>
>> methods to determine the timezone for a point<br>
>> - deferring the download of the boundary spatial data, so that it's<br>
>> not supplied with the plugin but instead the plugin automatically<br>
>> downloads it on first launch?<br>
>><br>
>> This would avoid the need for the large size plugin, allowing it to be<br>
>> supplied via the standard QGIS repo while still providing its full<br>
>> functionality...<br>
>><br>
>> Nyall<br>
>><br>
>><br>
</blockquote></div></div>