stamen / terrain-classic

World-wide CartoCSS port of Stamen's classic terrain style
ISC License
144 stars 35 forks source link

add contour lines from srtm 30m dem data? #45

Open clhenrick opened 8 years ago

clhenrick commented 8 years ago

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.

mojodna commented 8 years ago

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

clhenrick commented 8 years ago

thanks @mojodna I'll give that a shot!

mojodna commented 8 years ago

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

clhenrick commented 8 years ago

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

almccon commented 8 years ago

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

clhenrick commented 8 years ago

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

almccon commented 8 years ago

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

clhenrick commented 8 years ago

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

almccon commented 8 years ago

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?

clhenrick commented 8 years ago

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 commented 8 years ago

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

almccon commented 8 years ago

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.

clhenrick commented 8 years ago

Ha, yeah that's a pretty annoying issue!

clhenrick commented 8 years ago

@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.