Database maintenance

I’m going to do an OSM database reimport this weekend (Feb 25-26).

The web frontend will be online most of the time, so existing maps can still be retrieved, and new rendering jobs can be created, but the rendering daemon will be offline for at least all of Saturday, probably most of Sunday, too.

So don’t expect any new jobs entered over the weekend to be rendered before Monday, Feb. 27th, and the database may still be a bit behind for a few more days until things have fully caught up with minutely diffs again.

The problem with the current import is that I used the hstore-match-only option. So objects from the planet file that don’t have any of the keys set that are put into distinct database columns defined by the osm2pgsql style file used will not be part of the resulting database even if a hstore column for general tag storage is available.

This was not really what I had in mind, and it took a bit to figure out why the openPiste overlay, and the Pistemap style I’ve been experimenting with, did not show all ski piste segments. It turned out that these were the segments that only had “piste:*” tags on them, and not even a name or ref part, and that these were competely missing from the DB.

For a moment I had considered to set up a separate DB for these for now, but in the end doing a new full import replacing the old database looks like the better way to go.

2 thoughts on “Database maintenance”

  1. Progress:

    * Database import succeeded
    * Now catching up with 4 1/2 days of OSM diffs on the main database
    * Then with OSM diffs on the WayMarkedTrails DB (didn’t reimport that one, but had put diff updates on halt on that one during the reimport of th the main DB)

    Catching up with the diffs while take some time, I expect the main DB to catch up within a day, and the WayMarkedTrails one to take another day after that, so things should have fully caught up by Wednesday afternoon.

Leave a Reply

Your email address will not be published. Required fields are marked *