Q:

Correctly scale topographic SRTM data in OSM

I am trying to create contour maps in OSM with scales of 1:50,000 and 1:250,000 using 30-meter NASA SRTM data from here. Examples of what I'm trying to achieve can be seen on LINZ NZ Contours 1:50k and NZ Contours 1:250k pages:

Using methods strongly based on the OSM Contours page, I've managed to manipulate the SRTM data to render as follows:

I then tried to get something similar to Contours 1:250k by playing around with the rendering queries, but I've noticed my contour shapes are not exactly the same, and I fear I may be going about this the wrong way. Essentially, my query is almost identical to what's in the OSM Contours query section, except that I've modified the id: contours50 query to match WHERE height::int % 110 = 0. My attempt is on the left, the LINZ 1:250k version is on the right:

The commands I'm using to get all this into the database:

# Download .hgt file from NASA Earthdata

# Store .hgt file name in variable
source_file="S37E174"

# Prepare file for import
gdal_translate -q -co TILED=YES -co COMPRESS=DEFLATE -co ZLEVEL=9 "$source_file.hgt" "$source_file.tif"
gdalbuildvrt -q -overwrite SRTM1.vrt "$source_file.tif"
gdal_translate -q -co TILED=YES -co COMPRESS=DEFLATE -co ZLEVEL=9 -co PREDICTOR=2 -projwin 174.692262 -36.780183 174.818605 -37.028786 SRTM1.vrt srtm_30m.tif
gdal_contour -i 10 -a height srtm_30m.tif srtm_30m_contours_10m

# Import into database
cd srtm_30m_contours_10m/
shp2pgsql -p -I -g way -s 4326:900913 contour.shp contour | psql -h "$my_ip" -U postgres -d gis
shp2pgsql -a -g way -s 4326:900913 contour.shp contour | psql -h "$my_ip" -U postgres -d gis

My question: is this the correct way of scaling topographic information? Is there a better way of doing this?

A:

You're doing the right thing. I can't find anything on the LINZ pages to indicate the source of the contours you see on their pages, but there are at least a couple of possible reasons you see differences in the contours:

You are using higher resolution data than they did to produce your contours - your last image shows a contour which has a broadly similar shape but far more detail.
They simplified their contours to reduce complexity / make shapes nicer, and/or save data.

Below is an example - the original (left, file size about 5.5MB) produced from 30m SRTM data, the right processed with 'simplify geometry' in QGIS then smoothed (3.3MB):

 

