whitebox-python VS opentopodata

You can self-host an API serving open data (I also develop https://github.com/ajnisbet/opentopodata/ which helps you do this) but elevation data comes in different formats and quality levels which are non-trivial to merge without artefacts, and the datasets are too large for a typical cloud workflow.

Hi HN!

GPXZ ([https://www.gpxz.io/](https://www.gpxz.io/)) is an API for elevation point queries. These APIs are used for things like flight planning, flood analysis, elevation profile visualisation, and weather forecast localisation.

Google Maps is the name brand elevation API but it's expensive, you are restricted in how you use the data, they decrease accuracy for batch queries, and their dataset is being left behind by all the amazing open data sources released in the last few years.

You can self-host an API serving open data (I also develop [https://github.com/ajnisbet/opentopodata/](https://github.co... which helps you do this) but elevation data comes in different formats and quality levels which are non-trivial to merge without artefacts, and the datasets are too large for a typical cloud workflow.

So I built the 12 TB GPXZ dataset, which carefully merges open lidar and satellite sources covering the whole globe. The idea is that with a single dataset you can get the best-possible data in your area of interest.

The [gpxz.io](http://gpxz.io) API runs on a boring stack: nginx, uwsgi and python on dedicated servers. Everything is in a django monolith, except the API which I recently liberated from the monolith into a standalone flask service. I have a few freelance customers who are paying me for data processing and managed opentopodata hosting that have been extremely helpful in validating this idea.

I know this is a niche service compared to most Show HNs, happy to answer any questions about elevation data or geospatial APIs!

Cool, I learned about abstreet the other day from HN! Thanks for the feedback.

These days I run everything geospatial in docker containers, the dependencies in geo are tricky.

Interesting about the memory/caching issues. I was going to suggest rasterio which I use for batch queries in https://github.com/ajnisbet/opentopodata and comes bundled with its own gdal binary, but looks like you're already using that.

I've also used zarr+tifffile for geotiffs in particular, it's faster and avoids a lot of gdal's warts, but you still need something like rasterio to read the geospatial metadata and handle projections.