openmaptiles VS gdal

Openmaptiles uses docker-compose for its work. It fails flat on its face with podman.

OpenMapTiles

What is the advantage of this project over something like openmaptiles https://github.com/openmaptiles/openmaptiles

Flatmap calls into user-defined profiles in 2 places: first when processing each input element to map it to a vector tile feature, then a second time right before emitting all vector features in a layer.

That second call lets you manipulate vector features on each tile using JTS geometry utilities (i.e. merge nearby polygons or lines with the same tags). PostGIS uses GEOS which is ported from JTS so you have access to pretty much the same geometry utilities - often with the same name.

It's definitely not as flexible as a PostGIS based solution - especially if you join faraway features that don't appear on the same tile, but in practice it was enough to port the entire OpenMapTiles schema.

See the basemap layers package: https://github.com/onthegomap/flatmap/tree/main/flatmap-base...

For example see the landcover layer: https://github.com/onthegomap/flatmap/blob/main/flatmap-base...

Which was ported from the SQL contained in: https://github.com/openmaptiles/openmaptiles/tree/master/lay...

Also, this OpenMapTiles PR might help improve your pipeline after it gets merged: https://github.com/openmaptiles/openmaptiles-tools/pull/383

To fully self-host a route planner (e.g. a "Google Maps" equivalent) you need GraphHopper for the routing and two other parts: you also need some visualization aka "maps" (e.g. with OpenMapTiles) and you need the address search (e.g. with Photon).

Probably not the answer you're looking for, but I have been using openmaptiles to pull osm into postgres (in docker using quickstart.sh). If you can talk postgres in python then maybe that is for you?

TiTiler is a dynamic tile server built on FastAPI and Rasterio/GDAL. Its main features include support for Cloud Optimized GeoTIFF(COG), multiple projection methods, various output formats (JPEG, JP2, PNG, WEBP, GTIFF, NumpyTile), WMTS, and virtual mosaic. It also provides Lambda and ECS deployment environments using AWS CDK.

GDAL is the real heart, the python aspect is mostly wrappers around that I'm fairly sure. I love python for the record, the only reason I bring it up, is cause python haters accuse it of being slow, but QGIS drops down to C++ when speed is necessary, like most modern packages do.

gdal 0.15 (repo, docs), a set of Rust bindings for the GDAL library, used for access to geo-spatial data formats, is now out!

GDAL (Geospatial Data Abstraction Library) is a the geospatial data processing library. It handles a lot of Raster/Vector analysis and alteration. gdal_contour and gdal_rasterize which would be used to create isolines (contour lines) . There's more complex processing and analyses than that. More common is reprojecting multiple layers, and some that being as Vector files, into different coordiatne systems.

Access: GDAL

As an example we use GDAL heavily through its C# binds. We do all the additional data processing, that isn't done by the C++ GDAL, in C#. The final results are both Data (held in memory or temp exported to a file), and a normalized Raster Texture that we can display on a TextureRect. Most of the C# data processing scripts aren't even Inheriting from any Godot Class.

I think this would be the best way to handle this. GDAL is what you should look into for this project.