Code here: https://github.com/simonw/hmb-map
https://docs.protomaps.com/guide/getting-started#_3-extract-...
For the record, I am currently using maptiler over at https://citybik.es to serve tiles, and I am evaluating moving to serving static pmtiles on range requests to cut the middle man
I’ve been thinking of making a native map and globe program similar to Google earth to embed inside a dashboard (visually similar to kerbal space program).
So far I was thinking about just using ArcGIS (or something else) and taking in free Lidar data and imposing the depth to satellite or OSM tiles then rendering them as OBJs in OpenGL (or maybe a full 3d engine like unity). This unfortunately wouldn’t be an automatic process as lidar data is taxing to process in real time, especially for a SBC.
I do see that there are some 3D tiles sets out there but I don’t see where I can pull them from nor how it compares to the lidar data.
However, the main goal is a 3D terrain viewer in an offline native program.
You can get the heightmap from NASA. It's 10x10 meter resolution, which is enough for static geography.
Any information you have on how production-ready this is would be nice. Things such as performance, stability, max expected clients with a small vps or something.
- load balancing and caching. Some tiles are much more popular than others.
- how will you update the tiles (sync from OSM).
- if required, how will you manage customizations (and merges with OSM).
To add some value to my joke comment: I would assume this is running "Open Street Map" locally on a webserver.
With that said, the "tile hosting" part is notoriously difficult to actually self-host. It's a lot of data, it traditionally took a lot of time to transform the raw data into the png files representing the tiles. Many if not most web apps actually call out to openstreetmap.org or similar to do the tiles for them. That's not fully self-hosting. But more recently, there have been new ways to do tiles, namely with vector formats instead of pngs. They take up less space, they're easier to share around.
So this submission appears to be a simple few lines to get your fully self-hosted tile server of the whole planet up and running. You should then be able to use this in whatever web app you're making to make it fully self hosted (though if you wanted self-hosted search, that's another hard one...).
Hosting those is super simple. The problem I have is how to generate them efficently w/o big resources.
Not everyone knows what "OSM" is.
Even a 2-3 sentence paragraph in your TL;DR that explains (a) what this is and (b) why people should care or want this, would be immensely helpful.
Obligatory: https://xkcd.com/1053/
As is very common with projects on Github. They should have a paragraph at the start explaining simply what they do.
It might seem inconsequential, but maintainers often deal with a lot of angry entitled users and it could be helpful to stay away from language that implies that the people giving away their code for free (and for fun) have any obligation to provide anyone anything.
The problem with the whole OSM ecosystem is that it expects a lot of domain knowledge of technologies, formats, tools, their relations and features, limitations, that is rarely explained well, or explanaitions are often terribly outdated. Feels much like the JavaScript Frontend frameworks for an outsider, it is a lot of effort to get to an overview and understanding, despite the concepts are not new.
Because I understood about “the whole planet” in the context of OSM.
I can't really see doing it on S3, unless it's behind a lightweight tile server. I'd do it on hetzner or linode or one of the lower cost bandwidth providers.
(edit -- citybik.es is pretty cool, are you backing up to GBFS or a different set of data feeds? e.g. https://github.com/MobilityData/gbfs/blob/master/systems.csv is a list of ~ 800 gbfs feeds, some dockless, some docked I've done a bit of work in this space, feel free to ping me)
AWS Lambda: https://docs.protomaps.com/deploy/aws lightweight tile server: https://docs.protomaps.com/pmtiles/cli#serve
GBFS is just one format of the many supported. This is where we keep all instance data https://github.com/eskerda/pybikes/tree/master/pybikes/data . This is the list of GBFS systems we have https://github.com/eskerda/pybikes/blob/master/pybikes/data/...
https://pmtiles.io/?url=https%3A%2F%2Fdata.source.coop%2Fpro...
This is zoom 0-15, or 1,431,655,765 addressed tiles. So it is designed for this scale - for a production internet site you can add a lambda, server or CDN as an additional layer for lower latency: https://docs.protomaps.com/deploy/
Note though that there are many cases on which served tile information rarely changes. A lot of us are serving a once-downloaded mbtile file and are using this just to _not_ use a provider (mapbox, ...)
It depends on what you're doing, but outdated maps can be worse than no maps. On low zoom values that probably works fine, but new buildings and streets are built everyday all over the world.
If you need updates more often than once a week, you're going to have to take a different approach, since OSM only publish their database exports once a week. In that case you're going to have to use the OSM API to query their database for changes directly and it is only reasonable to track and manage continuous updates on a relatively small surface area.
All of this is of course ignoring the fact that there can be a time lag of anything from hours to decades between a house being built and that house being added to OSM.
Perhaps in a few years, as the project picks up uses and contributors, it will get its own website and support network and be easy to understand and use by "anyone."
It is more like a sample of cool stuff you can do.