terrain-classic icon indicating copy to clipboard operation
terrain-classic copied to clipboard

add contour lines from srtm 30m dem data?

Open clhenrick opened this issue 9 years ago • 14 comments

So after doing some research it looks like contour lines generated from SRTM 30m data could look decent up to about z15 and after that they start looking a little too jagged without smoothing them out.

I took an extract of an SRTM raster for the Mt Whitney area, extracted part of it, converted to EPSG:3857, then generated contours at 50m intervals. The following screenshots show the contours overlaid on top of the og terrain tiles in QGIS:

zoom 14 (~1:36,000) screen shot 2015-10-28 at 3 17 52 pm

zoom 15 (~1:18,000) screen shot 2015-10-28 at 3 13 19 pm

zoom 16 (~1:9,000) screen shot 2015-10-28 at 3 13 02 pm

zoom 17 (~1:4,500) screen shot 2015-10-28 at 3 18 51 pm

My general workflow for print cartography is to take the contours after rendering them with GDAL and use illustrator's "smooth lines" to apply bezier curves to them so they don't look so jagged. This could probably get them looking really nice at zooms 16+ but we'd have to figure out how to do it programatically.

clhenrick avatar Oct 28 '15 19:10 clhenrick

line-smooth is a nice CartoCSS way to smooth out jaggies. I tend to use it on longer lines and higher zooms.

mojodna avatar Oct 28 '15 19:10 mojodna

thanks @mojodna I'll give that a shot!

clhenrick avatar Oct 28 '15 19:10 clhenrick

line-simplify-algorithm: visvalingam-whyatt has also been helpful (and line-simplify is pixels in that case, i think) to further smooth lines.

mojodna avatar Oct 28 '15 19:10 mojodna

The line-smooth & line-simplify CartoCSS @mojodna pointed out is definitely helping, here are some samples rendered in TileMill:

zoom 16 screen shot 2015-10-28 at 5 15 29 pm

However at zoom 17 even with some line simplification the contours start to look a little jagged / unrealistic: screen shot 2015-10-28 at 5 12 28 pm

clhenrick avatar Oct 28 '15 22:10 clhenrick

What's going on with the background there? Is that what you mentioned about the gaps/overlaps between park areas?

almccon avatar Oct 28 '15 22:10 almccon

Yeah, that's where I noticed the seam between "green areas"

clhenrick avatar Oct 28 '15 22:10 clhenrick

Looks like an OSM error: screen shot 2015-10-28 at 3 04 00 pm http://www.openstreetmap.org/#map=16/36.5750/-118.2913

almccon avatar Oct 28 '15 22:10 almccon

Almost like someone plopped another polygon or redrew one on top of another?

clhenrick avatar Oct 28 '15 22:10 clhenrick

Or they were imported from two different datasets that had different generalization or different datums.

Or, even more of a nightmare: maybe those are the real boundaries... kind of like how the state borders are totally messed up along the Mississippi as the river moved but the legal boundaries didn't. Maybe there's something equivalent that happens on mountain ridges?

almccon avatar Oct 28 '15 22:10 almccon

Looks like one is an administrative boundary but also a "natural = divide" while another is a wilderness area:

screen shot 2015-10-28 at 6 11 00 pm screen shot 2015-10-28 at 6 10 39 pm

clhenrick avatar Oct 28 '15 22:10 clhenrick

Well for the meantime a879104 blurs the green areas' boundaries which should help hide these.

clhenrick avatar Oct 28 '15 22:10 clhenrick

darn this crowdsourced data! I mean, it looks like the wilderness area ought to join seamlessly with the other shapes, but instead the mapper traced it with new boundaries, it seems.

I'm going to mention it on the OSM IRC channels and hopefully somebody who is a better mapper than I am will fix it.

almccon avatar Oct 28 '15 22:10 almccon

Ha, yeah that's a pretty annoying issue!

clhenrick avatar Oct 28 '15 22:10 clhenrick

@mojodna anyway we could generate contour lines on the fly from Mapzen DEM data using the AWS workflow? Probably not feasible for the preview release but if possible might be a nice to have.

clhenrick avatar Jul 03 '16 19:07 clhenrick