Articles for Making on Visualizing.JP

What Is a Bar Chart Race?

Thu, 11 Jun 2026 00:00:00 +0900

A bar chart race is an animated form of bar chart that shows data changing over time, turning changes in rank and value into something that reads like a race. The format became widely known in 2019 after Financial Times data visualizer John Burn-Murdoch published a series of influential examples.

How to Read It

In a bar chart race, time advances along the animation while bars representing cities, brands, countries, or other entities grow, shrink, and change order. The viewer can immediately see which items rise, fall, overtake others, or disappear from the top ranks.

The appeal is not only that the chart moves. It is that the movement turns a long time series into a legible sequence of events. Pausing at a particular moment, slowing down the playback, or following one highlighted item can reveal the dynamics that a static table would hide.

John Burn-Murdoch’s example showing the world’s largest cities since 1500 made this especially clear: the viewer can see the center of urban scale shift from Europe and North America toward Asian and other emerging megacities.

Background

Animated ranked bars existed before the phrase became common, but Burn-Murdoch’s work spread widely on Twitter, now X, and helped establish the name “bar chart race.” Mike Bostock’s Observable notebook also contributed to the format’s diffusion by making the technique easier to inspect and reproduce.

What Is a Line Chart Race?

A line chart race, sometimes called a horserace chart, follows multiple series with animated lines. Instead of bars changing rank, the viewer watches lines rise, fall, cross, and compete over time. Flourish helped popularize this form around 2019 through an accessible template.

How to Read a Line Chart Race

Each line represents a participant such as a player, brand, party, or country. The vertical position may show either the actual value or the rank, depending on the mode. Crossings and reversals make the competitive structure easy to see.

Flourish templates typically let authors choose between score and rank modes, add images, attach captions, and focus attention on specific lines. The format works especially well for sports rankings, election polling, market share, and other time-based comparisons where the story is about momentum.

How to Make One

Bar chart race: Flourish templates, the Python bar_chart_race library, and Observable notebooks are common options.
Line chart race: Flourish’s line chart race template is a practical starting point. Upload a CSV, configure the columns, and customize the presentation.

These formats are useful when the key point is not a single final value but the story of change over time.

Summary

Bar chart races and line chart races are powerful animation techniques for communicating change, competition, and rank dynamics. Thanks to the work of John Burn-Murdoch, Flourish, and the broader data visualization community, they have become familiar tools for journalism, analysis, presentations, and public storytelling.

References

Natural Earth's POV (Point of View) Data

Fri, 27 Mar 2026 00:00:00 +0900

Natural Earth is a free, high-quality map dataset available at 1:10m, 1:50m, and 1:110m scales in vector and raster formats. Its cultural vector layers include political data such as country borders and administrative boundaries.

By default, Natural Earth displays boundaries based on de facto control: who actually controls a territory. Its POV, or Point of View, datasets provide alternative versions based on particular de jure claims or institutional perspectives.

What POV Means

In the Natural Earth context, POV means Point of View. It describes boundary data that reflects how a specific country or institution understands the world according to its laws, alliances, and official claims.

The default dataset uses a more neutral de facto view. But territorial disputes are often viewed differently by different states. POV variants make it possible to create maps from a Japanese, Chinese, American, or other official perspective. The number of countries and some boundary lines can change depending on the selected viewpoint.

Why It Matters

Political boundaries are not only geometry. They encode diplomatic position. If a map is used in education, journalism, product interfaces, or government materials, the boundary dataset can imply a position on disputed territories.

Natural Earth’s POV data makes this issue explicit by offering multiple boundary views rather than pretending that there is always a single universally accepted map.

Typical Uses

Internationalized map products
Educational materials requiring a particular official view
Comparative cartography
Diplomatic or policy analysis
Applications that must comply with local map display rules

Design Notes

State which POV dataset is used.
Avoid mixing different viewpoints without explanation.
Treat disputed boundaries as editorial and political decisions, not only technical data.
Keep metadata with the map so the source and viewpoint remain traceable.

Summary

Natural Earth’s POV data is useful because it acknowledges that political geography can depend on perspective. Choosing a boundary dataset is a design and policy decision, especially when maps include disputed territories.

What Is ADS-B?

Mon, 09 Mar 2026 00:00:00 +0900

Overview

ADS-B, or Automatic Dependent Surveillance-Broadcast, is an aviation surveillance system in which aircraft automatically broadcast their position. It is defined in standards such as the RTCA DO-260 series and is incorporated into ICAO aviation frameworks.

Aircraft use satellite navigation systems such as GPS to determine position, speed, altitude, and other values, then broadcast that information to nearby aircraft and ground stations. The FAA describes ADS-B as a system that complements traditional radar with more accurate and timely tracking.

How ADS-B Works

Aircraft commonly broadcast ADS-B messages on 1090 MHz using Mode S Extended Squitter. The messages include the aircraft’s 24-bit ICAO address and position encoded with Compact Position Reporting.

The broadcast is automatic. Ground receivers, other aircraft, and community receiver networks can capture the messages and reconstruct aircraft movement.

Data Contents

ADS-B data may include:

ICAO aircraft address
Latitude and longitude
Barometric or geometric altitude
Ground speed
Track or heading
Vertical rate
Callsign

Visualization Uses

ADS-B is widely used to visualize air traffic. It supports live flight maps, route analysis, airport approach patterns, airspace congestion analysis, and historical movement studies.

Design Notes

Coverage depends on receiver location and altitude.
Some aircraft may block or limit public display.
Position data can contain errors or gaps.
Dense airspace benefits from filtering, aggregation, and time animation.

Summary

ADS-B is a key data source for aircraft tracking and air traffic visualization. It provides detailed movement data, but good analysis requires attention to coverage, message quality, and aviation context.

What Is AIS?

Mon, 09 Mar 2026 00:00:00 +0900

Overview

AIS, or Automatic Identification System, is a maritime surveillance system in which ships automatically broadcast their position and identifying information. It is based on performance standards from the International Maritime Organization and is required under amendments to the SOLAS convention for many vessels.

Ships transmit information such as position, speed, course, and identity from GPS and other navigation systems. Other ships and coastal stations receive the messages, supporting collision avoidance and traffic management.

How AIS Works

AIS messages are broadcast over VHF radio. The ITU-R M.1371 standard defines message structures, including the vessel’s MMSI, position, speed, and navigational status. Transmission is automatic and can be received by nearby vessels, shore stations, and satellites.

Data Contents

Typical AIS data includes:

MMSI and vessel name
Latitude and longitude
Speed over ground
Course over ground
Heading
Navigational status
Vessel type and dimensions
Destination and estimated time of arrival when available

Visualization Uses

AIS data is useful for visualizing maritime traffic. Dense vessel tracks can reveal shipping lanes, port activity, anchorage patterns, fishing behavior, and unusual movement.

Design Notes

AIS data can be noisy or incomplete.
Position frequency differs by vessel speed and equipment.
Privacy, security, and commercial sensitivity should be considered.
Use aggregation when showing dense traffic patterns.

Summary

AIS is a foundational data source for maritime tracking and visualization. It provides near-real-time ship movement data, but analysis requires attention to message quality, coverage, and operational context.

The Evolution of Tableau Color Schemes

Mon, 16 Feb 2026 00:00:00 +0900

Tableau is one of the world’s most widely used data visualization tools, and its color schemes are central to how users read data. Color is not decoration: it conveys meaning, guides attention, and affects accessibility. This article traces the evolution of Tableau’s color design from the early 2000s, through the Tableau 10 release in 2016, to more recent changes around dynamic color ranges.

These changes reflect progress in visual perception research and user experience. The influence of color scientist Maureen Stone is especially important, and accessibility, color-vision diversity, and perceptual precision have remained consistent themes.

Early Tableau: Practical but Limited Palettes

Early Tableau palettes were designed to make charts attractive and immediately usable. They helped users create dashboards quickly, but the defaults were not yet as carefully tuned for perceptual uniformity or accessibility as later palettes.

As Tableau became a mainstream analytical tool, color had to support a wider range of use cases: categorical comparison, sequential magnitude, diverging values, highlighting, and dashboards viewed by many different audiences.

Tableau 10 and the Palette Redesign

The 2016 release of Tableau 10 marked a major redesign of the default palettes. The new colors were less saturated, more balanced, and better suited to repeated dashboard use. Tableau’s design team emphasized that the palettes were not simply aesthetic updates; they were built to improve legibility and reduce accidental emphasis.

The Tableau 10 categorical palette became widely recognized because it offered distinct colors without the harshness common in older default palettes. Sequential and diverging palettes also became more carefully aligned with perceptual principles.

Dynamic Color Ranges

More recent Tableau releases introduced more flexible handling of color ranges. Dynamic color ranges make it easier to preserve meaningful starts, ends, and midpoints even when filters change the visible data.

This matters because filtering can otherwise change the meaning of a color scale. If the same red no longer means the same value after a filter, readers can be misled. Dynamic control helps designers keep color semantics stable while still supporting exploration.

Why This Matters

Color schemes affect both accuracy and trust. Poor palettes can exaggerate small differences, hide important changes, or exclude readers with color-vision differences. Well-designed palettes support comparison, emphasis, and interpretation without drawing attention to themselves.

Design Lessons

Use categorical palettes for categories, not ordered values.
Use sequential palettes for values that increase in one direction.
Use diverging palettes only when there is a meaningful midpoint.
Preserve scale meaning across filters when possible.
Check whether the palette remains readable for color-vision-diverse users.

Summary

Tableau’s color schemes have evolved from practical early defaults toward more carefully designed, accessible, and semantically stable palettes. The story reflects a broader shift in data visualization: color is now treated as part of the analytical interface, not merely as visual styling.

References

Why Web Map Data Sometimes Mentions EPSG:4326 and Sometimes EPSG:3857

Sun, 16 Nov 2025 00:00:00 +0900

An EPSG code is an identifier assigned to coordinate reference systems, datums, projections, and related geospatial definitions. It tells software which coordinate system a geographic dataset uses.

Web mapping has a common source of confusion:

Should data for a web map be EPSG:4326, or EPSG:3857?

Documentation for Foursquare, Google Maps, Mapbox, MapLibre, Kepler.gl, Cesium, QGIS, and ArcGIS can appear to say different things. The reason is that there are two different uses of coordinates: input data and map rendering or tiles.

Conclusion

User-uploaded data should generally be in EPSG:4326.
Map tiles and rendering often use EPSG:3857 internally.

Input data layer -> EPSG:4326
Map tile and rendering layer -> EPSG:3857

Many people get confused because documentation may describe different layers of the system.

GIS tools such as QGIS and ArcGIS can handle many projections, so they are outside the main scope of this simplified web-map explanation.

GeoJSON Is Fixed to WGS84 Longitude/Latitude

The GeoJSON specification, RFC 7946, states that coordinates must be in WGS84 longitude and latitude. In practice, this means EPSG:4326.

Therefore, web mapping tools that accept GeoJSON generally assume input data in EPSG:4326. This is true across MapLibre, Mapbox, Kepler.gl, Cesium, Google Maps, and OpenLayers.

Map Tiles Use EPSG:3857

Google Maps popularized Web Mercator, EPSG:3857, and the web tile system based on z/x/y coordinates. OpenStreetMap, Mapbox Vector Tile, and many other web map systems follow this convention.

In other words, map tiles are usually in 3857 even though the data you upload is 4326.

Note on Cesium: Cesium accepts EPSG:4326-style longitude and latitude input, but rendering uses Earth-Centered, Earth-Fixed coordinates, EPSG:4978. The structure is still the same: input and rendering coordinates are different.

Internal Processing

A typical web map pipeline looks like this:

User data in EPSG:4326 longitude and latitude.
The map engine projects the data internally.
The display is aligned to the tile/rendering coordinate system, usually EPSG:3857.

So documentation that says “4326” may be correct for input, while documentation that says “3857” may be correct for tiles or rendering.

Does Any Tool Require EPSG:3857 as Input?

Almost none, if by “input” we mean ordinary user data such as GeoJSON. The main exception is vector tile generation. When data is being prepared as map tiles, then EPSG:3857 becomes relevant.

Do not confuse ordinary web map upload data with GIS servers or OGC services such as WMS and WMTS. Those systems can support many projections and have different design goals.

Method	Role	Projection	Feature	Typical use
Map tiles / XYZ tiles	De facto web map tile delivery	Usually EPSG:3857	Fast, cacheable, compatible with Google Maps and OSM	Web maps, apps, MapLibre, Mapbox, Kepler
GIS server	GIS-oriented map delivery	Flexible	Supports WMS, WMTS, tiles, analysis workflows	Government GIS, surveying, business systems
WMS / WMTS	OGC standard services	Flexible	More projection flexibility than web tiles	Public GIS and precision-oriented systems

Summary

Misunderstanding	Cause
“I do not know which EPSG to upload.”	Input coordinates and rendering coordinates are mixed up.
“Google Maps mentions both 4326 and 3857.”	One refers to input data; the other to tiles.
“MapLibre renders in 3857, so should input be 3857?”	GeoJSON input is still based on 4326.

For ordinary web map data, prepare longitude and latitude in EPSG:4326. Let the map engine project it for display.

References

What Is the Craig Projection?

Wed, 22 Oct 2025 00:00:00 +0900

The Craig projection is a map projection devised in 1909 by the British cartographer James Ireland Craig. It belongs to a special category called retroazimuthal projections: from any point on the map, the direction toward a specified reference point is shown correctly.

In other words, if a reference point is chosen, the map is designed so that the bearing from any location on the map to that point corresponds to the real bearing on the Earth.

Historical Background

The Craig projection is often discussed in relation to the practical need to know the direction of Mecca. A retroazimuthal projection can show the direction toward a chosen point from everywhere on the map, which gives it a distinctive purpose compared with more common world map projections.

Unlike projections optimized primarily for area, shape, or navigation, the Craig projection is centered on directional information toward a target.

How It Works

Most map projections choose a balance among distortions in area, shape, distance, and direction. The Craig projection makes a different promise: preserve the direction to one reference point from all other points.

This does not mean all directions are correct. It means the direction to the chosen point is correct. That narrow but powerful constraint gives the projection its unique character.

How to Read It

When looking at a Craig projection, first identify the reference point. The value of the map comes from reading bearings toward that point. The shapes of continents and oceans may look unfamiliar because shape preservation is not the main design goal.

Use Cases

Showing direction toward Mecca
Teaching projection trade-offs
Demonstrating retroazimuthal geometry
Data visualization examples where a specific destination or center matters

Design Notes

Clearly mark the reference point.
Explain that the projection preserves direction only toward that point.
Avoid using it for area comparison.
Use it as a focused explanatory projection rather than a general-purpose world map.

Summary

The Craig projection is not a minor variation of ordinary world maps. It is a projection built around a specific question: from anywhere on Earth, which way is a chosen point? Its religious and navigational practicality, combined with its mathematical elegance, makes it a useful example for understanding how map projections encode purpose.

References

Rethinking Color Contrast: From WCAG 2.x to APCA

Mon, 20 Oct 2025 00:00:00 +0900

Color contrast is essential in data visualization and web design. It is not only a matter of visual beauty; it directly affects readability and communication.

For many years, designers have relied on the WCAG 2.x contrast ratio. Recent work, however, has shown that the WCAG 2.x formula does not fully match human perception. APCA has emerged as a proposed direction for more perceptually grounded contrast evaluation.

What Is WCAG 2.x?

WCAG, the Web Content Accessibility Guidelines, is an international set of recommendations for making web content accessible. The 2.x series includes criteria for visual, auditory, motor, and cognitive accessibility.

The well-known “1.4.3 Contrast (Minimum)” criterion evaluates readability by calculating the luminance contrast ratio between text and background.

The Problem

The WCAG 2.x ratio is simple and widely implemented, but it can produce results that do not match perceived readability. Text size, weight, polarity, and human contrast sensitivity are not fully captured by one symmetric ratio.

What APCA Tries to Improve

APCA, the Accessible Perceptual Contrast Algorithm, aims to evaluate contrast in a way that better reflects human perception. It treats light-on-dark and dark-on-light differently and considers the practical visibility of text more directly.

Why It Matters for Visualization

Charts often use small labels, thin lines, subtle annotations, and colored backgrounds. A technically passing contrast ratio may still be hard to read, while some failing combinations may be perceptually acceptable depending on context. Designers need to evaluate contrast as part of real viewing conditions.

Design Notes

Check contrast, but also inspect actual readability.
Treat small text and thin marks conservatively.
Consider light/dark polarity.
Do not rely on color contrast alone for meaning.
Follow current accessibility requirements for production work while tracking APCA’s development.

Summary

WCAG 2.x contrast ratios remain important in accessibility practice, but they are not a complete model of perception. APCA points toward a more nuanced future for evaluating readability in web design and data visualization.

Vector Tile Style Specifications: Comparing Mapbox, MapLibre, and GSI

Fri, 17 Oct 2025 00:00:00 +0900

“Style JSON” files that define map design developed around the Mapbox Style Specification. Today, related specifications include the open-source MapLibre Style Specification and the Geospatial Information Authority of Japan’s GSI Maps Vector style specification. This article compares them using Mapbox as the baseline.

Historical Background

The modern style JSON format originated with Mapbox’s Mapbox Style Specification in the mid-2010s. It appeared alongside Mapbox GL JS and became a de facto standard for dynamic WebGL-based map rendering.

After Mapbox GL JS v2 changed licensing, the MapLibre project forked Mapbox GL JS v1 and continued open-source development. In Japan, the Geospatial Information Authority of Japan (GSI) also created a related style format for GSI Maps Vector.

Main Timeline

Year	Event
2013	Mapbox introduced vector tile technology in products such as Mapbox Streets.
2014	Mapbox announced Mapbox GL and style JSON-based rendering.
2019	GSI released a trial version of GSI Maps Vector.
2020	GSI began nationwide vector data provision.
2020	Mapbox GL JS v2 moved away from the previous open-source license.
2021	MapLibre was launched as an open-source fork of Mapbox GL JS v1.

Mapbox Style and GSI Style

Aspect	Mapbox Style Specification	GSI Maps Vector Style	Notes
Basic structure	JSON with `version`, `sources`, `layers`, `sprite`, `glyphs`	JSON-like hierarchy with `group`, `directory`, `item`, `layer`, `draw`	GSI adds hierarchical grouping
Layers	Listed in a `layers` array	Layers are grouped under UI-oriented structures	GSI aligns with its map interface
Layer types	`fill`, `line`, `symbol`, `circle`, `raster`, `background`, etc.	Similar basic draw types	3D support is more limited
Paint properties	`paint` and `layout`	Properties under `draw` such as color and weight	GSI simplifies many definitions
Filters	Mapbox expressions	Similar but more limited	Compatibility varies
Draw order	Array order	`zIndex`	GSI uses explicit numeric ordering
Extensions	None in the baseline	`additional-filter`, `blend`, `editZIndex`, etc.	Optimized for Japanese administrative map needs

Mapbox Style and MapLibre Style

Aspect	Mapbox Style Specification	MapLibre Style Specification
Structure	`version`, `sources`, `layers`, `sprite`, `glyphs`	Same basic structure
Purpose	Mapbox commercial platform	Open-source compatible implementation
Compatibility	Follows Mapbox’s platform direction	Preserves compatibility from the v1 fork
Governance	Mapbox-led	Community-led under MapLibre
Expressions	Advanced expression syntax	Largely compatible expression syntax
3D features	Includes features such as terrain, sky, and fog	Support depends on implementation progress
License context	Mapbox commercial ecosystem	BSD-style open-source ecosystem

Summary

GSI style extends the Mapbox-influenced structure for Japanese administrative and cartographic needs, including hatching and hierarchical UI grouping. MapLibre style preserves a Mapbox-compatible open-source path. All three are related, but they serve different institutional and technical goals.

References

Understanding Normalization and Standardization with Google Sheets

Thu, 16 Oct 2025 00:00:00 +0900

Good charts are not only about looking clean. They are about making fair comparisons.

When units and scales differ, comparing raw values can be misleading. Normalization and standardization transform values into a fairer form so that the underlying balance becomes easier to see.

Why It Matters

A food may look high in protein, but that impression can change depending on whether you compare per package, per gram, per calorie, or relative to the distribution of alternatives. The same problem appears in business, education, public policy, and data visualization.

Normalization

Normalization usually rescales values into a common range, often from 0 to 1. It is useful when you want to compare indicators that have different units but should contribute to a combined score or visual comparison.

Standardization

Standardization transforms values based on the mean and standard deviation. A standardized value shows how far an observation is from the average in units of standard deviation. This is useful when comparing unusualness across different variables.

Design Notes

Do not compare raw values when units or denominators differ.
Explain which transformation was used.
Keep original units available when readers need practical interpretation.
Use normalization for range-based comparison and standardization for deviation from an average.

Summary

Normalization and standardization are basic but essential techniques for fair comparison. In visualization, they help prevent scale differences from becoming visual bias.

Using Map Tiles Created in Mapbox Studio with Kepler.gl or Foursquare Studio

Wed, 15 Oct 2025 00:00:00 +0900

For some time, it has been possible to use map tiles and styles created in Mapbox Studio inside tools such as Kepler.gl and Foursquare Studio. In recent years, however, users have reported cases where specifying a Mapbox Studio style no longer displays the map and instead produces errors such as “Failed to load map style.”

The cause is related to changes on the Mapbox Studio side. This article summarizes why compatibility problems occur when Mapbox styles are used in other visualization tools.

What Changed

Mapbox styles, access tokens, source definitions, and platform-specific requirements have evolved. A style that previously worked as a generic style URL may depend on newer Mapbox-specific behavior, authentication rules, or resources that another tool cannot load directly.

Why Kepler.gl and Foursquare Studio Are Affected

These tools can consume external map styles, but they still need compatible sources, sprites, glyphs, and permissions. If the style references resources that require a Mapbox runtime, token scope, or newer style property support, the map may fail even though the style works inside Mapbox Studio.

Practical Checks

Confirm that the style URL is publicly accessible or token-authorized.
Check whether sprites and glyphs resolve outside Mapbox.
Confirm that the tool supports the style specification version and properties used.
Consider exporting or recreating the style in a MapLibre-compatible form when needed.

Summary

The issue is not simply that a style URL is wrong. It reflects the growing difference between Mapbox’s platform-specific style environment and the broader ecosystem of MapLibre, Kepler.gl, Foursquare Studio, and other tools.

Multicolor and Texture: A 1904 German Wheat-Yield Map

Thu, 02 Oct 2025 00:00:00 +0900

In 1904, the Imperial Statistical Office of Germany published a thematic statistical map of wheat yields. It shows both winter wheat and summer wheat, allowing yields per hectare to be compared across administrative districts of the empire.

Visualizing Many Classes

One striking feature is the large number of classes: up to 15 yield categories. The range runs from about 0.61 tons per hectare to roughly 3.4 tons per hectare, with the imperial average used as an important dividing point between below-average and above-average yields.

By modern standards, 15 classes is a lot. The map handles this by combining light-to-dark color with texture, including lines, waves, grids, and cross-hatching.

Low yields: pale pinks and oranges with fine line patterns.
Middle values: slightly darker colors with denser marks.
High yields: very dark tones with strong hatching and cross patterns.

The viewer can first read lightness as a broad low-to-high scale, then use texture to distinguish finer categories.

Design Under Printing Constraints

In the early twentieth century, multicolor statistical printing was technically and economically constrained. Subtle color differences alone would not reliably separate 15 classes. Pattern therefore became a crucial encoding channel.

The map is a good example of a hybrid color-and-texture design that turns production constraints into a visual strength.

Modern Perspective

Today, tools such as ColorBrewer help designers create legible and color-vision-aware schemes. A diverging color scale might be used for this kind of data. Still, the 1904 map succeeds in carefully layering information with limited means.

Summary

This wheat-yield map is an early and sophisticated example of multicolor choropleth design. It shows how cartographic clarity depends not only on color, but also on texture, print technology, and classification strategy.