Reimagining projections for the interactive maps era
mapbox.com
mapbox.com
Then we can use our built-in spatial reasoning to compare how big some areas are by changing the perspective (as in real life), and shapes are only distorted by perspective which is very familiar.
Also, many organizations, especially governments and news media, often have their own requirements and conventions when publishing maps — some practical, some purely stylistic. For example, NY Times uses Albers USA for election maps (it has that iconic curved look of state boundaries), and National Geographic uses Winkel Tripel for their world maps.
The maps were usually reprojected in variable UTM (according to your TZ - on the one I was working with) and/or using a Gauss projection, which is an extremely good compromise for whole countries. Because it was dynamic, the reprojection was a continuum while panning, usually imperceptible for the user at country scale. You could rotate the map, as well as query for road names in any spot instead of hunting down the (often missing) labels.
I feel like the online services regressed quite a bit compared to that time, but maybe that's just me as I was working on the field. The mercator projection was mostly a fallback for worldwide maps, hardly used otherwise at smaller scales. When google maps started to provide worldwide free maps (which could be used as a 3rd-party service for free at the time), there was no way we could compete. OSM wasn't good enough yet, data licensing from international vendors was extremely high, and worldwide satellite imagery required an entire order of magnitude higher investment to compete. The companies I knew all pivoted to fleet management and similar services to survive.
The transverse Mercator projection is an “extremely good” conformal projection for anything region located within a narrow band around a specified meridian. This describes some countries well (e.g. Chile, Finland, Vietnam, Portugal), but is rather terrible for anything stretched out East–West (e.g. Russia, Canada, Indonesia).
Among conformal projections, for a compactly shaped country the stereographic projection is better. For a country lying along a parallel, a conformal conic projection is better. For a skinny country oriented at an arbitrary angle, an oblique Mercator projection is better. For small enough countries, any conformal projection works fine with low distortion.
This allows to have of a country like Germany in view with very little distortion. As the zoom progressed outwards, it would morph to mercator. Nobody really noticed (sadly), and the choice of falling back to mercator was also due to it's popularity making it sort of "expected" more than anything else.
The key point is that the reprojection was dynamic, and done on the client, optimized for the current viewing conditions. Stuff that today you can perform via JS without any problem if you forego the idea that maps need to be pre-rendered.
If your display is tall and skinny and north always points upward, transverse Mercator is a good general choice among conformal projections. If your display is square or squat, then a stereographic or conformal conic projection is less distorted for any particular view.
> The maps were usually reprojected in variable UTM (according to your TZ - on the one I was working with) and/or using a Gauss projection, which is an extremely good compromise for whole countries. Because it was dynamic, the reprojection was a continuum while panning, usually imperceptible for the user at country scale. You could rotate the map, as well as query for road names in any spot instead of hunting down the (often missing) labels.
I'd be interested if you could remember any names because I don't remember anyone doing a good job with vector maps in 2005 when the google maps api came out (embedded google maps were long established by 2010). Performance would have been pretty atrocious even in Flash, especially if they were from any established GIS companies, where incredibly slow desktop software was already the accepted norm.
Maybe a very generous interpretation of continuous reprojection, but I'm not aware of any decent system like you describe until the early 2010s (like the one the article links to[1]) and even then there's no real products built around them, until now :)
[1] http://berniejenny.info/pdf/2012_Jenny_AdaptiveCompositeMapP...
We decided to go with live videos to demonstrate the concepts in motion, and because embedding WebGL vector maps on an already big page might slow it down quite a bit, but definitely something to consider more in the future.
One issue I noticed though is that if you use gestures to zoom on a touch pad, then you'll end up in the wrong spot.
For instance, I put my cursor on Sydney with a Lambert projection and pinch to zoom. As I pinch in, my cursor moves away from Sydney as the map rotates, so the centre of the map ends up at some other place.
Ideally, it should cache the geographic coordinates of the cursor at the start of the pinch gesture and zoom around that till it receives a non-pinch input.
I can see a value in having a "stable" map that doesn't twist around as you move, but I think that would offer a good alternative for people trying to look at places that suffer from the traditional projection centers, and of course different trade offs make sense for different circumstance.
But perhaps constantly reprojecting is too expensive?
Tangent: I have autoplay turned off in Firefox and had no idea half of these images were supposed to be examples of zooming in and out until halfway into the article, where one of them had a description.
This is not a critique on the article, just mentioning it for anyone else who might have similar settings. I'm also somewhat surprised that I don't even get a pop-up from Firefox asking me if I want to allow the video elements to be played.
(although I personally prefer my videos with controls enabling me to pause playback, instead of automatically looping fast-moving "gifs", which can get very disorienting while reading, but that's a different discussion)
Mapbox changed the license of their code last year I think to a proprietary one. https://github.com/mapbox/mapbox-gl-js/blob/main/LICENSE.txt
It requires a mapbox user license with billing enabled to use this code, let alone make modifications. But the source is viewable on github.
Mapbox also has one of the first tech unions established, but I do not think they have any position on the license. Any insiders know?
Its one advantage is that it demonstrates that the map is a picture of a spherical earth, but it shows only one hemisphere or less, and is heavily distorted away from the center
https://www.worldmapgenerator.com/
The first version of this project is from 2013, this version is afaik from 2017 and covers this topic the best way i've seen.
After 6 months Maplibre doesn't appear to have changed that much from the original MapboxGL version - which makes sense, because Mapbox pay a bunch of people a bunch of money to work on it full time.
And the engineering effort to implement this would be significant (probably an understatement, given how much this likely complicates the codebase going forward too). So I don't know where Maplibre will get the resources to do this (although it would be amazing if they did)
Do people just not know how to build websites without pulling in resources from a million arbitrary third parties any more?