opentopodata VS elevation_lookups

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.

https://github.com/eldang/elevation_lookups may be helpful. You have to find and hook up your own digital elevation model data, but then you can feed in OSM road line-strings

abstreet.org has an offline import process that combines data from OpenStreetMap, city-specific GIS datasets, and elevation into a single file. The process has to be deterministic, given the same input and code, and calling out to an external API is a non-starter. We use https://github.com/eldang/elevation_lookups, a Python library that downloads missing LIDAR or SRTM data and uses GDAL to handle batch queries. Two issues with it are having too many dependencies (so we run it in Docker) and not being able to parallelize lookups without blowing up memory, due to some GDAL caching internals.