Rapid icon indicating copy to clipboard operation
Rapid copied to clipboard

OSM Tag Frequency Counter for UI Color Analysis

Open chinweibegbu opened this issue 9 months ago • 0 comments

OSM Tag Frequency Counter for UI Color Analysis

TL;DR I used empirical analysis to identify the most relevant colors on the map for the purpose of creating colorblind-friendly map color schemes.

Overview

In order to create data-informed colorblind-friendly color schemes for the map, I measured the frequency of OSM tags rendered within a specific map extent.

This PR includes code incorporated from #1365. However, the main contribution of this PR is the chunk of code in /modules/pixi/PixiLayerOsm.js which does the OSM tag counting. This code was instrumental in #1384, specifically in the creation of three (3) colorblind-friendly color schemes.

NOTE: For the most part, this conversation is going to be held independent of the color system proposed in #1384

Thought Process Summary

Rapid has 39 distinct HEX colors referenced in /modules/core/StyleSystem.js and /data/colors.js. The aim is create colorblind-friendly color schemes in which:

  • All colors are colorblind-accessible
  • All color interactions are colorblind-accessible

One approach to this would be to create new color schemes which replace all 39 colors while ensuring the two conditions listed above.

A much simpler approach would be to focus on 5-10 colors which are most relevant to a colorblind user. That is what this PR addresses. The core question being asked is:

"How does one identify the most relevant colors on the map?"

Approaches

This section covers three potential approaches to answering the question above. Approaches no. 1 and no. 2 were attempted in the course of this PR. Approach no. 3 was not attempted due to the amount of resources and time it would require.

These approaches are NOT conclusive (hence the ISSUEs highlighted) and can be built upon further.

Approach no. 1

"How many times is each color referred to in the StyleSystem.js file?"

PROCESS: Use the file search function in whatever file editor being used

ISSUE: Does not account for how often that specific definition is rendered on the map e.g. red is only referred to once in StyleSystem.js but the feature that uses it (building) occurs the most on the map (specific to the evaluation map location)

Approach no. 2

Builds on Approach no. 1 by asking: "How many times is each OSM tag and value RENDERED?"

PROCESS: Programmatically count during the render() function call in /modules/pixi/PixiLayerOsm.js and print the results in console

ISSUE: Does not account for how features change across the map with changes in location and zoom level. >>> NOTE: One cannot evaluate the entire map at once because Render only renders the features (areas/polygons, lines and points) at a certain zoom level

Approach no. 3

Builds on Approach no. 2 by asking: "How many times is each OSM tag and value rendered ACROSS THE ENTIRE MAP?"

PROCESS: Move across the map in tiles/extents at every possible zoom and evaluate at every possible location >> Very rigorous, very time-consuming

ISSUE: Does not account for the relative size of the feature being rendered e.g. building is the OSM tag rendered the most BUT features like highway get rendered a lot bigger and take up more visual space

Results and Implications

This section is based on the data gathered in Approach no. 2. The frequency counter code chunk is dependent on the entities rendered in the current map extent (as specified in the URL used).

Research Context and Results

  • Map extent: map=15.53/6.6005/3.3352
  • URL: http://127.0.0.1:8080/#background=Bing&datasets=fbRoads,msBuildings&disable_features=boundaries&map=15.53/6.6005/3.3352
  • Console Output: Console Output
  • Link to Data + Sheet Descriptions: https://docs.google.com/spreadsheets/d/1M56K55LK4txRY_y68z0EESOMRL_y0974CLEvssZ4h3A/edit?usp=sharing
    • STYLE_SELECTOR Frequency (Specific): Contains the loaded STYLE_SELECTORS (osmkey and osmvalue), how many times each osmvalue was loaded, its assigned styleID, the color definitions attached to said styleID and previews of the defined colors (MOST IMPORTANT !!)
    • Color Definition (direct): Contains every hardcoded color value, the STYLE_DECLARATIONS in which it is used and how many times it is used
    • Color Definition (colors.json): Contains every color value defined by colors.json, the STYLE_SELECTORS in which it is used and how many times it is used

Research Implications

Based on the data gathered, I identified the 4 or 5 most frequently-used colors which heavily impacted accessibility. These identifications were further backed by visual confirmation using the colorblind emulators incorporated from #1365.

Once these colors were identified, the initial question - "How does one identify the most relevant colors on the map?" - was considered answered. You can check out the /data/color_schemes.json file in #1384 to see how these identified colors were redefined.

chinweibegbu avatar May 16 '24 02:05 chinweibegbu