It's subtle, but I just noticed these:

It looks like roads labels are drawn twice, first with a wide letter- or word-spacing, and then a second time slightly narrower. At first you don't notice it, or you think there are parentheses around the words.

Not sure how this is happening... they're not all double ways, I don't think. In any case, maybe text-min-distance or label-spacing is the culprit? Or more likely it's caused by attachments in the CartoCSS, where the label is defined in two places and gets drawn twice for the same feature.

Are there unicode versions of PT Sans? Not sure. If not, we need a fallback font.

We're labeling the name tag from OSM which will blindly pick up all local names. So we need to be ready for anything.

Also, Greenland is off-white, but I can live with that. Greenland is colored that way because of the landuse raster, but Antarctica is showing the no data value.

Maybe add a shapefile just for Antarctica? Pull it from Natural Earth?

Right now at zoom 18 (max zoom level) smaller roads (non-highways) are being displayed with casings, is this something we want to change for higher zoom levels with the updated terrain tiles?

Looks like the original terrain does a blur, which helps:

For the highway shields and airports:

• https://github.com/Citytracking/Terrain/tree/master/mapnik/shields
• https://github.com/Citytracking/Terrain/tree/master/mapnik/icons

Currently I've got terrain-classic (which includes everything) and terrain-classic-labels as the only two variants. We also need terrain-classic-lines and terrain-classic-background (which omits labels and lines).

Look at https://github.com/stamen/toner-carto to see how this is done. Also, compare terrain-classic.yml and terrain-classic-labels.yml in this repo, and extend the pattern to the other two variants. Also examine the tessera.json file in this repo to see how we serve up the variants.

For comparison, here are what the deployed styles look like:
http://maps.stamen.com/terrain-background/#13/37.7625/-122.3973
http://maps.stamen.com/terrain-labels/#13/37.7625/-122.3973
http://maps.stamen.com/terrain-lines/#13/37.7625/-122.3973

@almccon we should probably style park boundaries over water areas differently than those on land. What are your thoughts?

Here is what currently is happening:

Hi!
I have the same issue as stamen/toner-carto#36 .
Installed everything.

export DATABASE_URL='postgis:///terrain-classic'
make .env
The .env file is there.
make link, OK.
make db, OK, it creates the DB.
After that, the database is there and I can connect to it. It's empty.
make db/shared gives me the same errors as @jbcima .

psql:sql/functions/highroad.sql:1: NOTICE:  view "highroad_z15plus" does not exist, skipping
psql:sql/functions/highroad.sql:2: NOTICE:  view "highroad_z14" does not exist, skipping
psql:sql/functions/highroad.sql:3: NOTICE:  view "highroad_z13" does not exist, skipping
psql:sql/functions/highroad.sql:4: NOTICE:  view "highroad_z12" does not exist, skipping
psql:sql/functions/highroad.sql:5: NOTICE:  view "highroad_z11" does not exist, skipping
psql:sql/functions/highroad.sql:6: NOTICE:  view "highroad_z10" does not exist, skipping
psql:sql/functions/highroad.sql:26: ERROR:  relation "**osm_planet_osm_line_z10**" does not exist
LINE 18:       FROM osm_planet_osm_line_z10
                    ^
make: *** [db/functions/highroad] Error 3

Any idea from where it could come from? The README doesn't mention anything else before make db/shared.

If I try to keep going anyway, and do a make db/seattle, I get a

make: *** No rule to make target `data/aries/z4to10.json', needed by `db/aries'.  Stop.

All dependencies installed.
imposm3 version 0.1
Ubuntu 14.04.4 LTS

Thank you!

http://localhost:8080/flat/#9/17.8598/-98.4595

These cities fall right on a tile boundary, so they get labeled twice:

This is a special case of #17, but thinking about #43, it's a shame that mountains aren't rendered at all! Especially given that this map is about terrain!

OSM has peaks, so it wouldn't be too difficult to grab their styling and modify it. https://github.com/gravitystorm/openstreetmap-carto/blob/3bd384329e2cb6a627f99e034fcfb28e734dcbeb/amenity-points.mss#L945-L957

However, this is probably yet another can of worms that I shouldn't open right at the moment that we're trying to wrap this up.

Seems like some of these can be pulled in from Toner (eg: oceans and other bodies of water) but Natural Earth also has data for natural features at smaller scales / zoom levels. Could be a nice improvement to the original terrain tiles.

After #23 I think the landcover is looking really good at low zooms.

But when you reach the city scale, the colors are way too harsh.

I'm not exactly sure how I'm going to fix this, but I've got some ideas.

Probably not necessary at low zooms. I recall that we depend on water outlines at high zooms, but I don't remember exactly why.

Any plans to create a make for labels only? If not, any pointers for doing so? I just painstakingly made everything but labels transparent, which is a poor hack... .

When state highways aren't motorways, we should avoid giving them shields until you zoom in more. It's especially acute at zoom 11 where they are still drawn with a very thin line:

http://localhost:8080/#11/33.6138/-116.6968

Currently the city names disappear at z11, leaving the map looking pretty empty until street names starting to trickle in. OG Terrain keeps city names on the map until z16! I kind of like it.

When looking at Seattle I noticed an odd artifact at #10/47.1159/-122.0821. On zooming in it turns out to be a small tribal administrative boundary. We should probably add a query that prevents small admin areas from rendering at low zooms so we don't end up with black specs on the map.

Notice the speck below Prairie Ridge

Identified in QGIS:

Processes to add to the Makefile include:

• importing the Aries place data into PostGIS.
• process Aries from GeoJSON to SHP & reproject (only needed if the data isn't accessible via PostGIS)
• compile sub-directory of .mss files into single .mml files
• generate highway shields table in Postgres using sql/highway_shields.sql
• add ne_10m_admin_1_labels to PostGIS using sql/admin1_labels.sql
  (also requires dl'ing & extracting ne_10m_admin_1_states_provinces)*

* I imported the ne_10m_admin_1_states_provinces data into PostGIS by doing the following:

$ shp2pgsql -s 4326 -I -g geometry \ 
~/data/natural_earth_vector/ne_10m_admin_1_states_provinces_scale_rank.shp \
ne_10m_admin_1_states_provinces terrain_tokyo | psql -d terrain_tokyo

@almccon can you give me details so I can attempt to reproduce?

reference #12

Looks like with the new terrain-classic park boundaries aren't being rendered and that the landcover data is displaying at high zoom levels.

There must be a rule in cascadenik for the og terrain tiles that decides when to swap landcover data for park boundaries as the polygon layer to composite onto the hillshades.

Looks like at zoom 10 park boundaries start showing up, possibly on top of dimmed landcover data? Then at zoom > 10 park boundaries are more definitive.

I tried using them to adjust the sizes of the admin labels, but the populations are all nuts (I checked only the file admin-0-labels-z5. I thinks that Austria has a larger population than Germany, which is wrong, and which looks wrong on the map.

Why don't we have real populations in these files? Why don't we just use Natural Earth (where did these files come from, anyway?)

Here's me trying to use population < 90 to apply smaller labels. Totally wrong:

Don't think they need to be so dark

and they are much lighter in the og terrain tiles:

z9:

z9:

z8:

z7:

I'm only seeing this at <= zoom 9, and I'm only seeing it related to city labels, so possibly fixing #35 will fix it.

This is probably exceedingly rare, but I'm filing it just for reference:

At 14/38.3897/-122.9506 there's a service road where the name appears at zoom 14, but the road doesn't appear until z15.

We could definitely improve the typography by doing some simple things such as:

• spacing out the kerning via the text-character-spacing property.
• using italic fonts in labels such as water bodies, natural features, parks.
• varying the font-size of place labels based on something like scale-rank from natural earth
• creating angled labels along a path for features such as mountain ranges and valleys

@almccon & @mojodna does PT Sans Narrow have an italic font? I don't see it when inspecting via font-book. We might want to choose a font that has more options, at least one that has italic and bold-italic.

It seems to be happening at tile boundaries:

Oh, but in #35 we found some that were not on tile boundaries, although those seem to be fixed. But that's something to keep an eye on... I think they're only happening on tile boundaries, but I could be wrong.

The merged_labels is something I stole from another repo. It looks like the z4 and z5 city label areas don't have the justified column entered correctly.

QGIS screenshot, showing labels that are left justified in green, and those right justified in blue. Many more should be blue than are shown here.

Currently we're using the 5'x5' MODIS landcover from here: http://glcf.umd.edu/data/lc/ That's a raster of 1776 rows x 4320 columns.

That source also has a link to "native resolution" tiles, but it doesn't say what resolution those tiles are. Are they better resolution? We should find out.

previous

current

Noticed this while looking at the Hudson River in an New York extract. I'm guessing this is why there was a stroke applied to water polygons? I believe we previously removed at very low zooms but perhaps enabling them at higher zooms will fix this. That or a union in PostGIS?

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)

zoom 15 (~1:18,000)

zoom 16 (~1:9,000)

zoom 17 (~1:4,500)

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.

Looks like it's got spots:

Something didn't go right for me when I re-made the natural earth data / imported to postgres. Maybe try using shp2pgsql instead of ogr2ogr?

Here's the extent of the previous source data:

It's higher-resolution than what I'm using now for the world. Unfortunately, the categories seem to be fairly different between the two rasters. It would only look weird where the two rasters are up against each other. Unfortunately the old data cuts off in Mexico... otherwise I could maybe use the old data for all of North America and make the transition in Panama somewhere. But it looks like I need to make the transition along the US-Mexico border.

Old data:

New data:

Actually, it won't look too bad in most places. Maybe just awkward at the border with Baja California

See #26 for more discussion.

In this screenshot, Mexico City should show up. http://localhost:8080/flat/#8/19.329/-98.871

I'm not sure why the default shield isn't showing up, but when I use extracts outside the US I don't get any highway shields, and when I use extracts of other US states, I don't get any of their state shields.

previous:

currently:

I added code in https://github.com/stamen/terrain-classic/blob/master/Makefile#L266-L281 to load Natural Earth shapefiles into the database, but it needs more rewriting: currently if you already have the NE shapefiles downloaded the Makefile thinks there is nothing to do.

This error occurs if you're trying to set up a new database extract, but you already have NE downloaded for a previous extract.

The makefile needs to test for existence of the db tables, not just the existence of the shapefiles.

Seems like we should be able to easily port these from Toner? Though perhaps it depends on how we address the dymo placement of labels (ref #4)

currently we have none

Where available from OSM. Will cover over landcover issues in airports:

It's a nice touch in Toner, but it would be nice to make this map look less like Toner

http://localhost:8080/background/#15/37.7775/-122.4386

Because the labels files we are using were generated for Helvetica, not the narrower font we want to use for Terrain, the alignment of city labels looks bad.

By default, the labels are centered within the label polygon, and are usually way too far from the city dots.

If I try to text-align using the justified field in the data, like so...

  [justified='left'] {
    text-horizontal-alignment: left;
    text-dx: 15;
  }

  [justified='right'] {
    text-horizontal-alignment: right;
    text-dx: -15;
  }

...I can never get things to line up correctly.

(these examples include the following debugging code, to see the text polygon in the background)

  ::outline {
    polygon-fill: #fff;
    polygon-opacity: 0.3;
  }

Here's Mt. Baker at z9, showing only the landcover data. Nice white-topped mountain:

Then at z10 we start drawing national forests, and this ice-covered peak looks solid green:

OSM has good glacier features... we should draw them:

...but I think I will have to pull out yet another OSM feature in imposm.

Looks like there is a casing on the trails as they now exist

Whereas the original terrain tiles are a simple dashed dark gray line