The problem with maps // Playing with Projections

One of the core ideas covered in my talk named “Geoshizzle” on mapping is that the Mercator projection is way overdue. It’s main feature of preserving angle measurements is no longer feasible in this time and age (it was back when you were sailing a boat to get somewhere), and it’s distortion of areas has affected how we perceive the size of the world (e.g. Greenland and Antarctica really aren’t that big).

Michael Davis has created a really good article on this, filled with visualisations using Tissot’s indicatrices demonstrating the effects of each projection.

Pictured above you can see Tissot’s indicatrices drawn onto a globe, an equirectangular projecten, and the Mercator projection

A Frenchman named Tissot came up with something fancy. The general idea was to characterize local distortions; To show you what a small circle would look like when moved from the globe to the map.

The coolest part of the article/site is that the visualisations are interactive: you can give each globe a spin and simultaneously see how (the distortion of) the linked projection is affected by it.

The problem with maps →

👉 Want to see how the Mercator Projection affects the shape of a country when drawn on a map? Play the interactive Mercator Puzzle to find out.

(via Lensco)

Google Maps’s Quiet Transformation

Justin O’Beirne kept an eye on how a specific area evolved on Google Maps and on Apple Maps over time:

Patricia’s Green is the centerpiece of a vibrant and trendy neighborhood in central San Francisco, just blocks away from City Hall.

I wrote a script that takes monthly screenshots of Google and Apple Maps. Thirteen months later, we now have a year’s worth of images

On Apple Maps, the area looks much as it did a year ago. But it’s quite a different story on Google Maps: as the months went on, Google continued adding detail.

As a mapping aficionado, I’m intrigued by this kind of stuff 🙂

A year of Google Maps and Apple Maps →

Using Machine Learning to Predict Parking Difficulty

No monitoring of parking meters, video feeds, etc. Looking at the users their behavior is the way to do it:

Google determined that if users circled around a location like in the picture above, it usually suggested that parking might be difficult. To recognize this behavior, they took the difference between when they should have arrived at the location versus when they actually arrived there, with a large difference indicating more difficulty in finding a parking spot.

Using Machine Learning to Predict Parking Difficulty →

Crafting Data-Driven Maps

At Uber, we use maps for everything — visualizing millions of geo data points, monitoring road conditions, and advocating for policy change in cities around the world.

Over the last few years we have experienced immense growth. As a result, we have many teams across the organization producing map visualizations for a wide range of needs. We saw a need to create a unified system to guide the creation of consistent, high-quality, data-driven maps.

Crafting Data-Driven Maps →

deck.gl – Large-scale WebGL-powered Data Visualization

deck-gl

New open sourced project by Uber Engineering, for visual exploratory data analysis of large datasets:

At Uber, the many GPS points we process every day serves needs across the company. If we have a problem in our platform, we can diagnose it by exploring historical geolocation data. If there’s an accident on the road, we can explore GPS traces for a given trip to get full context. If there are pain points around pickup locations in a city, we can communicate plans to city authorities by visualizing them. We need this data to be web-based, real-time, and shareable so other teams at Uber can use it. To meet all these needs, we developed deck.gl.

You can visualise different types of layers:

You can also jump start any data visualization project with deck.gl’s set of core layers, including the scatter plot, line, arc, choropleth, and grid layers, or you can optionally connect to other third-party libraries like our popular open source framework react-map-gl. […] We’ve also developed layers to visualize 3D building structures, street segments, point-cloud data, and more, which we will be open sourcing in future releases.

A very simple instance would be this:

import DeckGL from 'deck.gl/react';
import {ArcLayer} from 'deck.gl';

const flights = new ArcLayer({
  id: 'flights',
  data: [] // Some flight points
});

<DeckGL width={1920} height={1080} layers={[flights]} />

Note that this example will yield no underlying map. You’ll need the aforementioned react-map-gl for this. Somewhere hidden in the docs you’ll find:

The DeckGL component is typically rendered as a child of a map component like react-map-gl, but could be rendered as a child of any React component that you want to overlay your layers on top of.

The DeckGL React component works especially well as the child of a React component such as react-map-gl that displays a map using parameters similar to the deck.gl Viewport (i.e. latitude, longitude, zoom etc). In this configuration your deck.gl layers will render as a perfectly synchronized geospatial overlay over the underlying map.

Visualize Data Sets with Uber Engineering’s deck.gl Framework →
deck.gl →
deck.gl Trip Routes Demo →

Sidenote: whilst the docs are technically correct, they seem a bit rushed and are not very usable at this moment to get started with deck.gl. The examples themselves are very nice, but clicking the “source” tab only gives you half the picture as they’ll only display the source of the DeckGL container, sans its wrapping MapGL component. In short: You’ll have to puzzle a bit to get this thing started.

Related: Vizicities

TopoJSON

topojson

TopoJSON is an extension of GeoJSON that encodes topology. Rather than representing geometries discretely, geometries in TopoJSON files are stitched together from shared line segments called arcs.

[…]

TopoJSON eliminates redundancy, allowing related geometries to be stored efficiently in the same file. For example, the shared boundary between California and Nevada is represented only once, rather than being duplicated for both states. A single TopoJSON file can contain multiple feature collections without duplication, such as states and counties. Or, a TopoJSON file can efficiently represent both polygons (for fill) and boundaries (for stroke) as two feature collections that share the same arc mesh.

A converter to convert your GeoJSON to TopoJSON is available 🙂

TopoJSON →