What if Earth’s terrain was created by nighttime lights?
Note: This post could have been written in puns alone, but I’m going to hold myself back from that and try to be a good person. But I mean if you want me to shed some *light* on the situation and step out of the *shadows*, this wasn’t a *night*mare to make…
Another note: I think Sarah coined the term “mountains of light”. I like it, thanks!
Here’s the general workflow of how the code works:
- Get that elevation layer wired up to Nasa’s nighttime lights satellite imagery server.
- Ok fine, if you really want to geek out with me, it comes from the Suomi-NPP VIIRS sensor.
- The polished and cleaned up pixels are called “Black Marble” and provide a 500m image resolution.
- This isn’t live data but rather a static composite of images taken at different times. Joshua Stevens and Rob Simmons helped me get a better understanding of the hard work that went in to creating and cleaning up this raw imagery into a beautiful worldwide dataset.
- Back to the code: for every nighttime light pixel, convert the visual color ramp that goes from dark blue/black to yellow/white into a simple 0-1 number range. For this I used the chroma.js “luminance” calculation.
- Take the 0-1 number value and multiply it by some huge number! We don’t want 1 meter tall mounds, we want wild and exaggerated mountains reaching high into the sky.
- Drape anything you want on top of this fake terrain. In this case it made sense to also put the nighttime lights imagery on top of the terrain that it generated.
This is a view of northern India, the Himalaya, Nepal, Bhutan, and the Tibetan plateau with our fake mountains at night.
If we drape daytime satellite imagery over this synthetic terrain it is hard not to notice something is a bit off with the Himalaya. Viewing the Earth this way wasn’t the original intent of the app, but it is fun to look at if you don’t mind the headache.
And here’s a bunch of other links to keep you going down the rabbit hole.
Visit the app here: https://jwasilgeo.github.io/esri-experiments/earth-at-night/
At Petrichor Studio we like to use D3 for our interactive, web-based visualizations.
Below are a couple code samples to help you get started making a simple world map in your browser. One approach shows you how to render GeoJSON data in your browser as graphics using SVG, while the other approach uses Canvas. They can be compared side-by-side and I encourage you to identify their similarities and differences.
The overall pattern goes like this
- Set up the element that will render the graphics of your map. Choose
<canvas> and give it an initial width and height.
- Establish the map projection. We want to make a two-dimensional map, but our geographical features exist on a three-dimensional planet. We’re going from longitude/latitude coordinates to a flat map and D3 needs to know how that should happen. Read up on Map Projections on the Web when you’re ready.
- Create a D3 geographic path generator and tell it about the map projection. This is the workhorse that instructs SVG or Canvas how to create two-dimensional graphics out of GeoJSON data.
- Load your spatial data. The samples below use a network request to load publicly available world country geometries in the TopoJSON format. TopoJSON is more or less a special format of GeoJSON. It just takes 1 extra step to convert from TopoJSON to regular GeoJSON. No big deal.
- Use the geographic path generator to convert your data into graphics. The longitude/latitude coordinates will be drawn as map graphics in the
Simple D3 Map using SVG
See the Pen Simple D3 Map using SVG by Jacob Wasilkowski (@jwasilgeo) on CodePen.
Simple D3 Map using Canvas
See the Pen Simple D3 Map using Canvas by Jacob Wasilkowski (@jwasilgeo) on CodePen.
If you are just getting started with D3 the best advice I can give is simply what worked for me: read other people’s tutorials and code samples, all while experimenting on your own until perceived failures become replaced with tiny successes. The tiny successes will become bigger over time and failures won’t seem so scary or annoying anymore.
Good luck! We’ll revisit these topics in more depth by focusing on Map Projections on the Web.
Even though it is already May, the college basketball excitement and hype of March Madness inspired me to do a sports-related data visualization or mapping project. It was a lot of fun working with animations for the gerrymandering topic in What’s Your Vote Worth?, and it eventually crossed my mind to explore Formula 1 circuits.
What we do here is stack all the circuits on top of each other, like misshapen pancakes, and show you only 1 at a time. Even though they’re scattered throughout several continents, here they share the same space and the same map scale. Then, we continually move on to another circuit by morphing between the current shape and the next shape in the pancake stack. The world reference map is also updated to provide geographical context.
An argument for doing this (other than just because I can) would be that you can directly compare the circuits’ shapes, sizes, and orientations, without having to find and navigate to each circuit separately as with a traditional web map.
I wanted to style this with an 80’s retro racer vision of a neon, cyberpunk future we’re all speeding towards, so we employed SVG and CSS effects along with an awesome font to achieve the final look. (Thanks, Sarah!)
If you visit ESPN’s website, you can find the team rosters for all the NCAA Basketball teams that made it to the NCAA tournament. On that site, ESPN lists the players’ number, position, year, and hometown, among a few other statistics. A couple of my colleagues, Nick Brueggemann and Gregory Brunner, did some mapping with this data. I asked them if I could take their dataset and crunch it a little further. There is a ton more that could be done with this information. And maybe I will someday, but here’s what I have done for now to spatially visualize the NCAA D1 Basketball Tournament team roster data:
I decided to map the women and men athletes’ hometowns as graduated symbols, where hometown sizes are based upon the amount of athletes that come from there. The men and women hometown maps are separated in order to more easily identify the different locations. These maps started out with world city points and labels, but I removed them for the sake of decluttering the visualization. I was able to identify the lat long of the athletes’ hometowns using ArcGIS. I then calculated the distance from each player’s hometown to the city that their team is located; here is a really handy blog post that someone wrote eleven years ago; I often refer to that post when calculating distances between lat long coordinates. Calculating the distance of each athlete’s hometown to their team city allowed me to identify the average recruit distance per team, along with the farthest (and closest) recruit distance. Other than the maps themselves, I haven’t done any visualization for teams on the lower end of the average recruit distance. (Maybe in few days ?) There are a lot of players whose hometown is also the the same as their team’s city.