Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You can also prerender the tiles on a powerful machine and host them on a cheap instance (assuming you don't need very large regions). A while ago I created an OSM server (https://github.com/seemk/TileSweep) to do this for me, you can select regions you want to render via a polygon and you get a SQLite database of the tiles. It can also run as an alternative for mod_tile + renderd.

I rendered all of Estonia from zoom levels 0 to 18 (~16.5M tiles) which is around 20GB and host the tiles on a cheap DigitalOcean instance.



* How is the workflow for updating OSM data with this project?

* What is the recommended procedure for backup + restore?

I find a lot of projects in this space make you go through an manual copy-paste setup process like if it was a one-time thing - it is not - updating OSM data is a crucial part in this process and should be part of it.


I haven't investigated updating of data using anything clever. I know the database load script can write out a list of tiles that need to be rerendered, which can be fed into the renderd process. Renderd has multiple priority channel so bulk renders are a lower priority than user views, so a live system can update the tilecache without much easier impact.

I haven't investigated it because we are probably moving to Vector tiles over the next month or two, and we don't need up to the minute map updates. On one of our sites, we have been rendering navteq tiles and we only get updates for those quarterly. It was only our public site that we were using Google Maps for.

Backup and restore we are just doing via normal backup programs. The tilecache is stored in meta tiles, which is a d duplicated set of 64 tiles in a single file. So we are only dealing with about a million files in a directory structure totaling 25 gigabytes.

If we needed to restore or update our tiles, we would probably just spin up a new box and rerun ansible to deploy it. I have it all encoded Within a Playbook.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: