Different map styles ("lenses")

[tordans]

This issues is part of #11168.

This issue will be updated with ideas and solutions on how to introduce the advanced user features in kaligrafy/iD to the broader user group of iD users.

Right now this issue is a stub with meeting minutes from a discussion with @kaligrafy, @tyrasd and @tordans who meet online to talk about #11168. There are many issues and some solutions for this topic already. I will try to collect some to allow us to get a broader pictures and discuss next steps.

---

Goals

• Introduce map styles that allow to efficiently map one theme
  For example side walk mapping, street side parking.
• Use map styles to get live quality assurance while mapping
  Eg. Highlight when one or a set of required tags are missing.

Adding map style capabilities will allow for accessibility features as well es features like dark mode along the road.

---

Context
The fork at kaligrafy/iD has custom map styles that are used by the trained mappers that use this fork. It allows them to extract a lot of information just from the style.
The style highlights

• data on maxspeed
• bike infrastructure
• buildings types
• highlight objects that do not follow a embedded minimum field requirements

The goal of this ticket is to explore how those advanced user features can be added to iD without mudding the experience for new and unexperienced users.

Different kind of map styles

• Styles that replace the current style completely
  (This is what kaligrafy/iD does, for example)
• Styles that add a set of layers below (or above) the current map style
  (This is what the "Highlight unsaved features" in iD does, for example)
• Styles could disable editing of features as part of the style
  (Eg. disable building and borders when editing side walks)
• Styles could hide or "gray out" features that as part of the style
  (Eg. Gray out buildings, POI when editing maxspeed)

---

Research: What do we already have…

(This list does not have to be complete. Its more about getting a bigger pictures to better scope the feature.)

iD Issue this Topic

#6616

• A unique idea for a name for this feature in iD: "Lenses"
  • JOSM calls it "Map Paint Styles" 🔗
• A list of ideas what to highlight for iD 🔗
• An idea on where to expose this in the UI, once it is ready for every day use 🔗

Highlight unsaved edits
This feature is already a map style in iD that is applied as additional layers below the current style.
We will probably want to consolidate this to be applied in the same UI.

• PR with Screenshot: Add hotkey for Visual Diffs  #6843

Rapid: Pedestrian Focus Mode
There is a draft PR in Rapid showing how a style can highlight the data that is needed for a mapping task and at the same time hide (or gray out) unrelated data.

• PR with Video: Pedestrian Focus Mode facebook/Rapid#1394 (comment)

Rapid: Heatmap
Not directly related to map styles, but the general topic: Rapid introduced a heatmap style to make it easier to find areas that need work

• Locator Overlays aka 'Heatmaps'.  facebook/Rapid#1437

Rapid: Color blind modes
Rapid has to options, one to pick the map style and one to pick a color blind modification mode.
The modification mode uses code that Maputnik also uses to transform the colors 🔗 .

• PR with Video: Add colorblind mode facebook/Rapid#1230

Dark mode
A system for map styles would allow us to have a dedicated dark mode style along the way

• Feature request: ID Dark Mode #8214

---

Current research questions

• Look into MapCSS and if/how we can use it for iD. (Eg: It might be too slow…) @kaligrafy
  • The bigger question is, what styling "language" we want to use. Stay with what iD has now. Move to MapCSS. Move to what Rapid has (JSON). Move to something else that is out there… — In The styling issue facebook/Rapid#451 there are a couple of notes on this topic.
• Look into the Rapid Color System to evaluate if this architecture would be a good fit for iD. (Eg: It might be too entagled with the Pixi map rendering or bigger refactorings that took place…)
  • See https://github.com/facebook/Rapid/pull/1190/files which adds colors in Rapids context / systems architecture
  • The related issues explain what was done New Feature: Color System facebook/Rapid#1187 and Color System: Part II facebook/Rapid#1213
  • There was more work on this in Color-Style System Re-Structuring and Colorblind Accessibility facebook/Rapid#1384 (comment) but not merged

[kaligrafy]

MapCSS in iD editor and comparison with Mapbox Studio

Pros of MapCSS in iD Editor

Familiar Syntax & Standards

MapCSS is already the established styling language for OSM tools like JOSM, so there's existing knowledge and documentation. It uses CSS-like syntax (obviously).

OSM-Native Features

MapCSS was designed specifically for OpenStreetMap data, so it handles OSM tags, relations, and data structures naturally. It includes built-in functions for common OSM styling needs like handling highway classifications, building types, etc.

Powerful Conditional Logic

MapCSS has complex conditional styling based on tag combinations, zoom levels, and feature relationships, useful for mapping applications where context matters.

Community Ecosystem

There are existing MapCSS stylesheets, tools, and community knowledge that could be leveraged rather than starting from scratch.

Cons of MapCSS in iD Editor

Performance Overhead

MapCSS parsing and evaluation can be computationally expensive, especially for complex rulesets. iD needs to stay responsive during editing, so this could impact user experience. We will need benchmarking here. We can provide a simple, fast style as default, and allow power-users to use more complexe patterns, accepting performance overhead.

Limited Visual Design Capabilities

Compared to Mapbox Studio's visual interface, MapCSS seems code-heavy. It lacks some styling features like smooth gradients, advanced label placement, or visual effects that users expect from contemporary mapping tools. The official MapCSS 0.2 specification defines color properties as simple color values like "color: blue", "color: #00F", or "color: rgb(0.0, 0.0, 1.0)" but includes no gradient functions like linear-gradient() or radial-gradient(). The specification only supports solid colors and basic fill patterns. it may be possible to extend MapCSS to also use standard CSS attributes, but it may require more refactoring. Specification

Complexity for Non-Developers

While CSS-like, MapCSS still requires CSS coding knowledge, so the default style should be robust enough for most users. Mapbox Studio's drag-and-drop interface is more accessible to designers and non-technical users, but there are open-source studio-like tools for MapCSS. Feel free to comment if you know some examples.

Rendering Constraints

MapCSS was designed for different rendering contexts than web-based editors. We might hit limitations in how certain styles translate to the web rendering pipeline iD uses.

Alternative Considerations

We might want to evaluate whether a hybrid approach could work - using a visual interface that generates MapCSS under the hood, or creating a simplified MapCSS subset that covers the most common styling needs while maintaining performance.

WebGL?

Since the iD editor will (I hope) implement webgl in the near future, we should start thinking about this right now, since applying mappcss to webgl will be more complex than simply styling SVG paths, but MapLibre can give us cues here on how to use css and convert it for shaders.

Some references

Gradient Support

Performance Concerns: JOSM's bug tracker documents specific performance issues with MapCSS evaluation, including ticket #16977 which describes "possible performance problem in MapCSS based Tag checker" where complex selector evaluation creates computational overhead #16977 (Possible performance problem in MapCSS based Tag checker) – JOSM.

References for Mapbox Studio Capabilities

• Mapbox
• Mapbox Blog: Style