add aerialways

[claysmalley]

Fixes #500

Breckenridge, Colorado, US:

La Paz/El Alto, Bolivia:

Aletsch Arena, Valais/Wallis, Switzerland:

Medellín, Colombia:

[ZeLonewolf]

The great American inspiration: James Niehues:

Definitely works better against a snow map. I suppose there's no way to differentiate skiing arialways from transportation ones.

The Bolivia case seems to get especially cluttered. I wonder if perhaps it would benefit from a strong knockout and a softer line color.

[claysmalley]

Adjusted the width so that the knockout casing shows up better:

[1ec5]

I think “aerialway” is only a real word in OSM English. Both aerial trams and chair lifts count as aerial lifts.

[ZeLonewolf]

Chairlifts or gondolas on the east coast.

[ZeLonewolf]

Tram sounds like some quaint en_GB thing to me.

[claysmalley]

Aerial lift sounds good to me as a general term.

The two transit-oriented aerial lifts I know of in the United States have tram in their names:

• Portland Aerial Tram
• Roosevelt Island Tramway

I think "aerial tramway" in US English is reasonably understood to be a transit-oriented aerialway=gondola or aerialway=cable_car. But at a ski resort, I'd definitely call that a gondola.

[jleedev]

Shucks, landuse=winter_sports isn't in the tiles.

[ZeLonewolf]

Yeah, a little background on that:
https://github.com/openmaptiles/openmaptiles-skiing

[wmisener]

The bright red makes these features very visually prominent, and thus by implication very important (though the width adjustment helped make them a bit more muted). That prominence makes sense enough on a map of a single ski resort, especially with their snow-white backgrounds, but I'm not sure it's right for a general purpose map. I don't know if these aerialways are that much more important to a typical user than, e.g., railways, which render much more subtly. This especially strikes me in the examples in urban settings.

On Americana so far, red has been reserved for freeways and trunk roads, so this would change/dilute the meaning of the color red in the style. The current casing style also makes them look quite similar to a trunk-expressway IMO. I wonder if it would be more consistent for these features to be purple, the designated "transportation" color (although I think airports are the only thing rendered in that class so far), as has been toyed with for busways in #477.

[1ec5]

I agree that it would be confusing to overload red to mean either an important road or something very different, especially since the two can cross. There’s a limit to how much inspiration we can draw from a site map of any kind, whether a ski resort, golf course, or shopping mall, since a site map can afford to deemphasize anything off-site considerably. If we need to maintain a connection to ski resort maps, perhaps pink (with a white casing) would be sufficiently distinct from a road, but it would need to be desaturated a bit to avoid overwhelming the map.

[claysmalley]

Here's a sample of purple, pink and red, all desaturated a little:

[quincylvania]

Color aside, I think these might benefit from rendering little dots for the endpoints, any intermediate stations, and maybe at higher zooms the aerialway=pylon nodes. This would indicate the distinctive cable infrastructure and allow lines to stand out while having a thinner stroke. Like you could probably go down to one centered stroke here (showing just stations at this zoom, not poles):

osm-carto takes a nod at this approach but doesn't use the actual locations of the poles, just a pattern, which I personally find a little misleading and silly-looking at high zooms.

[claysmalley]

Aerialway stations tracked in #692. I think matching the color of aerialway lines is a good idea.

Unfortunately aerialway=pylon isn't present in the tiles, otherwise it would definitely be implemented in this PR.

[adamfranco]

+1 for the purple option. I like how it fits the transit theme and also its visual weight. It's distinctive enough to be able to follow through the myriad grayscale lines of Bolivia without jumping out too much.

[adamfranco]

Also, at very high zooms the knockout might be dropped to let the wires stand alone as they cross over buildings and other features at something approximating a realistic width. With pylons (at some point) that effect could be really neat.

[claysmalley]

Changed to airport purple. Here are some aerialways near airports for context:

[claysmalley]

Line gap now significantly widens at very high zoom:

[ZeLonewolf]

The purple is definitely an improvement over the red. What is the distinction between the double-thin lines and the strong dashed lines?

[claysmalley]

Dashed line, feet touch the ground. Two parallel lines, you're five stories up.

[claysmalley]

Note in the Courchevel example above, there are two drag lifts (dashed lines) that pass under road bridges. Ideally, layer would be exposed here, but for most cases we can assume drag lifts are at layer=0 and aerial lifts are at layer=6.

[ZeLonewolf]

For inspiration, an areial tram on SwissTopo.

I like that it's desatured and thinner. Wondering if we can try that but with our purple hue. Also consider long-dashes.

[1ec5]

The legend doesn’t correctly implement line-gap-width, making this legend entry look misleading: #770.

[claysmalley]

In case anyone was worried that drag lifts would clash with political boundaries:

[zekefarwell]

Of the three colors shown in screenshots so far, the pink looks best to my eyes. I also find the endpoint dots Quincy suggested help set the aerialways apart from other liner features. Something like that seems like a good idea.

The low zoom screenshots with a single line rather than a double were looking more chairlift-like to me. I wasn't sure why until I went looking at ski resort trail maps and remembered that they generally just use a single line. Maybe a single line would work well at higher zoom levels too?

Or maybe there are other types of maps that commonly show aerial lifts as double lines?

[claysmalley]

Of the three colors shown in screenshots so far, the pink looks best to my eyes.

There seems to be some conflicting opinions on the color. I do like the purple, though I suspect whatever color we use here is likely to become the public transit color. Purple would make train stations and bus stops hard to find within airports.

I also find the endpoint dots Quincy suggested help set the aerialways apart from other liner features.

Aerialways always start and end at stations, which are POIs that I intend to implement separately. #692

The low zoom screenshots with a single line rather than a double were looking more chairlift-like to me. I wasn't sure why until I went looking at ski resort trail maps and remembered that they generally just use a single line. Maybe a single line would work well at higher zoom levels too?

Cables are typically 15-20 feet apart in real life. There aren't many high-zoom examples of aerialways on maps, but at a zoom level where indoor features could potentially show up, it looks clunky to me if this gap isn't present. I could probably adjust the threshold to a higher zoom level, though.

[1ec5]

Regarding the color, I think the bubblegum pink or the red has a certain flair that fits with the Pop Art labeling. Makes it feel sportier. But a more muted purple is fine too. The important thing is that no one would mistake it for a kind of road,¹ and I think purple accomplishes that.

Footnotes

1. Ironically, if we had chosen black or gray for runways, as many print maps do, we probably could’ve gotten away with making aerialways the same color. Readers wouldn’t have as much of an expectation that the color indicates the kind of conveyance. ↩

[1ec5]

By the way, the screenshot in #755 (comment) seems to be showing an aerialway name of the format Line: Terminus ↔ Terminus, which is a controversial part of the PTv2 tagging scheme that places non-name data inside name. Is this a common occurrence, and are we expected to hide names used in this manner?

[claysmalley]

By the way, the screenshot in #755 (comment) seems to be showing an aerialway name of the format Line: Terminus ↔ Terminus, which is a controversial part of the PTv2 tagging scheme that places non-name data inside name. Is this a common occurrence, and are we expected to hide names used in this manner?

I haven't seen that outside of Bolivia. I agree that the termini shouldn't be in the name, but that is a tagging issue for local communities to solve. I wouldn't bother with writing extra code to hide names that conform to suspicious PTv2 tagging.

[ZeLonewolf]

While red would be great on a ski-specific map, I think having purple be the general-purpose transit color makes sense as visual language. And the doubling at high zoom is a nice touch.

The one thing that stood out to me is that the font descents obscure the lines a bit. Are we okay with that or should the text be offset a bit more?

[claysmalley]

I added a text offset, though it seems to be offsetting in the opposite direction half the time and I'm not sure why:

[claysmalley]

One last change: magenta. Because if we're gonna need to repurpose this color for public transit, it can't be the airport purple, since airports aren't necessarily passenger transport facilities. Also, I'm gay for transit 🏳️‍🌈🚡

I think this is as good as it's going to get for now. Tail work:

• aerialway stations (part of Points of Interest #692)
• aerialway pylons not present in tiles
• text-offset is applied in the wrong direction on lines that appear right-to-left when line-gap-width > 0. Am I doing something wrong or is this a Maplibre bug?

[ZeLonewolf]

Regarding:

text-offset is applied in the wrong direction on lines that appear right-to-left when line-gap-width > 0. Am I doing something wrong or is this a Maplibre bug?

Can you summarize what's different between aerialway rendering and road rendering that would cause this bug to appear in one case and not the other?

[claysmalley]

text-offset is defined in src/layer/transportation_label.js, and it only applies to aerialways so far. When the direction of a line as mapped on OSM goes right-to-left across the screen, the offset seems to work in the opposite direction as expected.

line-gap-width may be a red herring, as it's only present in src/layer/aerialway.js.

[1ec5]

Here’s one of those test areas above:

Setting text-keep-upright to false illustrates the problem:

Essentially, we’re expecting text-keep-upright to flip the symbol onto the other side of the line, but all it does is flip the text itself around the text-anchor, which is currently set to bottom.

One workaround would be to set text-anchor to center, centering the text over just one of the lines:

With a wider knockout, it could do a good job of emphasizing that there are two parallel lines as opposed to a casing.

[1ec5]

Essentially, we’re expecting text-keep-upright to flip the symbol onto the other side of the line, but all it does is flip the text itself around the text-anchor, which is currently set to bottom.

Moreover, I think this GL JS behavior is pretty reasonable. For example, the boundary edge labels in #52 shouldn’t flip across the line based on text-offset, because that would overlap with the other side’s label. If we wanted a different behavior in the renderer, it would have to be some other text-anchor value that’s lower than bottom.

[claysmalley]

Setting text-anchor to center and increasing the offset seems to have the effect we're looking for:

[ZeLonewolf]

Looks good. I think it's time to get this change in the map!