[1] https://news.ycombinator.com/item?id=44455787
[1] https://news.ycombinator.com/item?id=44455787
They’re a data science team mostly but the main “data processing engine” that they solely rely on was written by a dude who split right as he “finished it”. No one knows how it really works. Black box style. Has been “the way” for 5 years. I’m not sure if no one cares, or no one cares to care, but they don’t seem to want to change it. Maybe it works, but also funny how many business critical decisions are made based on the code that everyone has only ever “just trusted”.
colkassad•1d ago
Don't get me wrong, it's a fantastic and ancient coral reef of a library and tool set but has a lot of inconsistencies in naming conventions and usage (gdal_translate, gdalfinfo). Many geospatial professionals are not savvy enough to leverage it without it being wrapped by someone else like Esri. Windows power users typically install it with something like OSGeo4W [2], whose name I can never remember. Whenever I need it I spin up a Docker image for convenience.
[1] https://github.com/OSGeo/gdal [2] https://trac.osgeo.org/osgeo4w/
perrygeo•1d ago
You'll be interested in the changes in 3.11, a single `gdal` entrypoint with a modern CLI. https://gdal.org/en/stable/development/rfc/rfc104_gdal_cli.h...
Installation is still a beast, mainly because it's one monolithic thing. It's a spatial analysis library, dozens of applications, and hundreds of filetype drivers - all in a single build process. Each driver has its own quirks and the abstraction leaks like a sieve. In retrospect, I think the spatial logic, the drivers, and the apps should have been broken up into loosely-coupled components. But the convenience of an all-in-one megalith was hard to beat.
colkassad•1d ago