I also dislike the title ("What we learned when a user tried to load a massive GML file in a browser") - it's hard to imagine that someone who had tried to build a viewer for geospatial data would not already know the answer (paraphrasing, "tiling the data will be necessary to achieve acceptable performance, and there are standard methods to do this")
This article seems to be worse than most, as if someone's deliberately overused the LLM tropes as much as possible. This is not good. It's bad. This is not human. It's AI. This is not nice to read. It's awful.
I feel this is a little disingenuous, especially given it then says QGIS takes ~10 mins to open the same file and then doesn't give a time for ArcGIS.
As much as I have respect for QGIS and what it's capable of (especially given its price point!), it's not always that fast: I recently looked into why drawing polygons interactively was so insanely slow (with the help of perf on Linux) in QGIS, and the code was basically suffering from 'painters algorithm' and is just a really inefficient implementation with loads of redraw and 'find-nearest-point' overhead.
I wouldn't be surprised (as another example: until recent releases, Blender's OBJ format importer was similarly orders of magnitude slower than other DCC apps OBJ importers - e.g. it would take > 2 hours to import a large .obj file other apps could ingest fully in under 30 seconds) if the code path just hasn't been looked at and optimised.
I also dislike the title ("What we learned when a user tried to load a massive GML file in a browser") - it's hard to imagine that someone who had tried to build a viewer for geospatial data would not already know the answer (paraphrasing, "tiling the data will be necessary to achieve acceptable performance, and there are standard methods to do this")
I feel this is a little disingenuous, especially given it then says QGIS takes ~10 mins to open the same file and then doesn't give a time for ArcGIS.
As much as I have respect for QGIS and what it's capable of (especially given its price point!), it's not always that fast: I recently looked into why drawing polygons interactively was so insanely slow (with the help of perf on Linux) in QGIS, and the code was basically suffering from 'painters algorithm' and is just a really inefficient implementation with loads of redraw and 'find-nearest-point' overhead.
I wouldn't be surprised (as another example: until recent releases, Blender's OBJ format importer was similarly orders of magnitude slower than other DCC apps OBJ importers - e.g. it would take > 2 hours to import a large .obj file other apps could ingest fully in under 30 seconds) if the code path just hasn't been looked at and optimised.