Add places labels using Aries data

[clhenrick]

We may want two layers for this data, one for labels and another for points at low zooms similar to the og terrain.

[clhenrick]

also am modifying the .gitignore file so that the repo contains the aries data as it's not currently downloadable via url.

[clhenrick]

Not sure if it's necessary but I renamed the column "zoom" to "scalerank" for the aries data thinking that it might cause issues when writing cartocss:

# copy the json to shp so the attribute fields can be renamed, be sure to use UTF-8 encoding
ogr2ogr --config SHAPE_ENCODING UTF-8 data/aries/z4to10.shp data/aries/z4to10.json 

# create the projected version of the aries data with the zoom column renamed to scalerank
ogr2ogr -f 'ESRI Shapefile' \ 
-t_srs EPSG:3857 \ 
-skipfailures \ 
-sql "Select name, zoom as scalerank, population, capital from z4to10" \ 
shp/aries_places_merc.shp \ 
data/aries/z4to10.shp

[clhenrick]

Think the city labels are looking fairly good, at least for the Bay Area :)

[almccon]

AWESOME!

[clhenrick]

@almccon using the shield CartoCSS styling for aries places seems to solve the issue we were having with urban areas that have a lot of suburbs. The only downside I'm seeing to this method is that when attempting to use shield-placement-type: simple; doesn't work too well. This limits your labeling position to one place instead of many.

Here are some screen shots from zoom 4 to zoom 10.

[almccon]

Interesting. It's not bad... it almost feels intentional. But I dunno, I don't think it's quite right.

[clhenrick]

I'm at a loss of what else to try then, other than running Dymo. Here's what happens when ditching the y-axis offset and using shield-placement-type: simple;

[almccon]

I feel like the solution to this is something Seth will remember off the top of his head, but will take me a bit of time to remember. He's on a plane today, but let's ask him about this tomorrow.

[mojodna]

2 potential options:

1. shield-unlock-image to disconnect the marker from the text (potentially allowing for more placement options)
2. Draw markers first (with marker-ignore-placement: true--assumes that there aren't crazy numbers) and then add text symbolizers (using the advanced placement options). This will result in dots for all cities, but only labels that fit.

[almccon]

Definitely option 2 was looking very weird. Unless we can do some smarter filtering on the aries data, there were tons of unlabeled dots scattered around places like Mexico City and Paris

[clhenrick]

@mojodna I'm currently attempting 1 but it seems that using shield-placement-type: simple; with shield-placements: 'NE, N, NW, SE, S, SW'; isn't changing much; I'm only seeing labels being placed above or below the "shield" / marker:

I don't think I attempted to do 2 with marker-ignore-placement: true; so will give that a go. With this option would you recommend duplicating the aries layer for markers and labels? Or just leaving it as a single layer?

[mojodna]

Did you try shield-unlock-image: true? You may also need to add shield-text-dx and shield-text-dy values to give it somewhere to go (I think the alternate placements ignore / negate as necessary).

For (2), you can keep it as a single layer. By defining the markers first (and ignoring their placement), they'll always show up but won't prevent text symbolizers from showing up.

[clhenrick]

@mojodna I did use shield-unlock-image: true; Adding shield-text-dx and shield-text-dy works when setting text-position: dummy but you end up with the label in the same position every time.

[mojodna]

Oh, hmm. I just had a look at https://github.com/parks-conservancy/map-labels/blob/master/labels.mss and https://github.com/parks-conservancy/map-labels/blob/master/icons.mss (where we did similar stuff) and realized that we never tried shifting the position of shields...

Given that, (2) might work better, though extra points (and colliding points) will be a problem. By duplicating the layer, you can reset the label collision cache (clear-label-cache in the 2nd layer's properties in the YAML file) after the markers are drawn (not ignoring placement, so getting nicely spread points). This would require that the city points be the first layer involving labels, as all previously placements will also be cleared, resulting in overlap.

[clhenrick]

@mojodna okay I'll give that a shot

[clhenrick]

Results:

[almccon]

I'm content with the above/below labels. I've convinced myself that it looks intentional. :)

[clhenrick]

Cool

On Friday, September 18, 2015, Alan McConchie notifications@github.com wrote:

I'm content with the above/below labels. I've convinced myself that it looks intentional. :)

— Reply to this email directly or view it on GitHub https://github.com/stamen/terrain-classic/issues/26#issuecomment-141605792 .

-Chris L Henrick

MFA, Design & Technology Parsons, The New School For Design

http://chrishenrick.com Github: @clhenrick https://github.com/clhenrick Twitter: @chrislhenrick https://twitter.com/chrislhenrick

“Whenever I see an adult on a bicycle, I no longer despair for the future of the human race.” — H.G. Wells

[clhenrick]

@almccon I finally got the randomized label placement to work via some SQL, here's what it looks like, pretty decent I think:

[clhenrick]

@almccon if you prefer the above / below feel free to revert and I promise I won't be offended :)

[almccon]

Interesting. So that's just totally random? On the resulting map it looks intentional (like for example Xoxocotla and Tlaquiltenango south of the city, which looks like the labels were correctly positioned to avoid colliding. But in reality it's just because those two happened to have randomly-preselected positions that didn't overlap... and that there are other cities in that area that simply didn't get shown?

And why is Mexico City not labeled in that screenshot? What label is it colliding with? Shouldn't it have higher priority than any other labels? (that might be a separate problem).

I'm inclined to revert this because I don't like depending on randomness... and it also makes the style nondeterministic, which will be confusing when trying to debug styles... we won't be able to exactly duplicate each others' random numbers, so our styles won't match exactly.

[clhenrick]

@almccon yeah I was surprised at the outcome too. I think what's happening is that Mapnik is picking the labels that don't conflict which is why it looks rather hand-placed. Not sure why Mexico City isn't showing up. Is there a way to use the zoom / scalerank column to determine a priority of labeling in TileMill Mapnik?

[almccon]

Well, we can (and should) make sure that the records are sorted in the right order when they're returned from SQL and fed into Mapnik. We can 'ORDER BY' scalerank and population. Do you want to give that a try?

[almccon]

I think I fixed the label placement. Not sure what I'm doing differently here.

[clhenrick]

Sure, that makes sense. Will give it a shot!

-Chris L Henrick

MFA, Design & Technology Parsons, The New School For Design

http://chrishenrick.com Github: @clhenrick https://github.com/clhenrick Twitter: @chrislhenrick https://twitter.com/chrislhenrick

“Whenever I see an adult on a bicycle, I no longer despair for the future of the human race.” — H.G. Wells

On Mon, Sep 21, 2015 at 4:43 PM, Alan McConchie notifications@github.com wrote:

Well, we can (and should) make sure that the records are sorted in the right order when they're returned from SQL and fed into Mapnik. We can 'ORDER BY' scalerank and population. Do you want to give that a try?

— Reply to this email directly or view it on GitHub https://github.com/stamen/terrain-classic/issues/26#issuecomment-142103044 .

[clhenrick]

That looks much better!

-Chris L Henrick

MFA, Design & Technology Parsons, The New School For Design

http://chrishenrick.com Github: @clhenrick https://github.com/clhenrick Twitter: @chrislhenrick https://twitter.com/chrislhenrick

“Whenever I see an adult on a bicycle, I no longer despair for the future of the human race.” — H.G. Wells

On Mon, Sep 21, 2015 at 5:45 PM, Alan McConchie notifications@github.com wrote:

I think I fixed the label placement. Not sure what I'm doing differently here.

[image: screen shot 2015-09-21 at 2 44 31 pm] https://cloud.githubusercontent.com/assets/1212178/10006003/5de35922-606f-11e5-92ee-93c4061eaa5a.png

— Reply to this email directly or view it on GitHub https://github.com/stamen/terrain-classic/issues/26#issuecomment-142118970 .