[sideband]

QGIS is fantastic and that team deserves a lot of praise for their work over the years. However, the article calls out using KML as a data source and unfortunately QGIS does not have the best support for KML. One of the reasons KML is still around despite it's faults is because a KML author can easily design a UI for their data in Google Earth, organizing data by folders with descriptions, including pre-defined views and image overlays among other things (a basic example here: https://kmzview.com/5qBGblENff4w0RkQf89J). Then, anybody who opens that KML in Google Earth gets that same UI. There are a lot of casual consumers of this type of data and this experience is powerful for them. I think QGIS could really broaden their appeal to this casual user base by supporting these well-loved KML features.

[otter-in-a-suit]

TIL. I used what I got from my rural county’s website / GIS (hence kml) - I wonder if I could get proper shape files by calling their GIS department.

[dvdkon]

Shapefiles are no more proper than KML, I'd even say KML is a better format, since it's a single file and doesn't have the archaic name limitations of SHP.

[anakaine]

KMLs do not have a spatial index. Reading a properly constructed shapefile with 2m points is fine, and running a SQL query on it is also fine. Trying to do that with an xml based file is not fine. Each of the major GIS packages spends quite a bit of effort to convert kml to an in memory spatially indexed dataset on ingestion. Shapefile conversely does not have to sit entirely in memory to still be reasonably quick.

Shapefiles do have the anyone field name length limit, among a few other things, but alternate formats that recognise that issue have existed and been popular for well over 20 years.

In other news, geopackage is based upon sqllite, supports long field names, a good assortment of data types, and is finding good adoption among many facets of spatial products from desktop to scripting, etc.

[dinkumthinkum]

Shapefiles are faster to read.

[larodi]

use PostGIS with proper spatial indices, and properly tuned if you have to take the QGIS way. and remember that spatial SQL is always better than using python-based analysis. particularly with newer versions of Postgre where there is chance that the queries be parallelized.