tangram
tangram copied to clipboard
tangrams
proposal -- map legend creation
Add a legend parameter to allow users to specify draw elements to be used to generate a map legend.
The legend colors would based on colors and style specified by a draw element. This way, if the user changes colors and styles, the legend would update dynamically.
The user would specify a display name for the label in the legend parameter, which would also toggle the inclusion of that draw element in the legend
The legend itself would be drawn in GL and defined as a special legend layer, where the style of the box, text style and background are defined.
layers:
borders:
data: { source: borders}
international_border:
filter: { admin_level: 2 }
draw:
lines:
color: aqua
width: 2px
order: 10
legend: "national border"
regional_border:
filter: { admin_level: 4 }
draw:
lines:
color: green
width: 2px
order: 20
legend: "regional border"
industrial:
data: { source: industrial }
draw:
polygons:
color: yellow
lines:
color: blue
width: 2px
legend: "industrial area"
capitals:
data: { source: capitals }
draw:
points:
color: blue
width: 2px
legend: "capital cities"
legend:
draw:
lines:
color: black
width: 2px
polygon:
color: [1,1,1,0.5]
text:
color: black
size: 14px
family: Helvetica
align: top-right
Reminds me of Carto.js options for legends (which are a "good thing" in general, though probably a 2017Q1 task after v1 Tangram):
- https://carto.com/docs/carto-engine/carto-js/api-methods/#sublayerlegend
- https://github.com/CartoDB/cartodb.js/search?utf8=✓&q=legend
:+1: to the idea of being able to build a legend out of data in the scene file. Legend creation has been a long-standing issue with OSM carto and the only sane way to do it is something automatic
Interesting idea. While it wouldn't be hard to extract legend names/groupings from the syntax you suggested, color can be a bit trickier, because it can both vary by zoom and/or by feature (or arbitrary JS function). For zoom-based color, we could update with the current color value, but I'm not sure how we would appropriately evaluate truly dynamic colors. For display, we would likely just do this via CSS (in Tangram JS) instead of having any custom GL-based drawing. And the data would be directly available for users to display as they wish with a custom control.
And the data would be directly available for users to display as they wish with a custom control.
👍
For those of us that want complete control over the view layer, this is important. I agree that GL rendering of legends is unnecessary. If Tangram.js needs to generate its own markup and css it should only be very basic. Mapmakers should be free to choose their own methods for creating legends to fit their own styles and application structure (for instance, Mapzen.js could then create its own view layer, using Mapzen styleguide rules, within a Leaflet layer).
@dmvaldman also pointed out that rendering a nice-looking default legend style could be something that mapzen.js does, rather than Tangram core.
Another interesting question is whether this markup should be in the scene file, or somewhere else. I like that the legend name is used in the scene file. This can be parsed out in Tangram and some legend object made available to something like Mapzen.js, or third-party.
+1 on Tangram providing a legend object to end users and mapzen.js. Adding a ticket to mapzen.js to build out default legend UI, following this issue: https://github.com/mapzen/mapzen.js/issues/313
