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.
What shines through here is that the AI writing / reasoning this is about as lazy as always, declaring a hard limitation where some engineering might solve or work around the limitations. In modern JavaScript a surprising amount of tasks can be handled, e.g. with Workers and in a streaming way.
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 can’t handle reading articles that seem to be AI assisted text. It is incredibly grating. I wish HN had an AI filter or something.
I agree that the text is unpleasant to read.
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.
What shines through here is that the AI writing / reasoning this is about as lazy as always, declaring a hard limitation where some engineering might solve or work around the limitations. In modern JavaScript a surprising amount of tasks can be handled, e.g. with Workers and in a streaming way.
If I wanted to read an LLM output, I'd prompt the machine myself
> ”But Desktop GIS Can Handle It” — No, It Can’t
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.