Mapbox-gl-js: Support non-mercator projections

[mike-marcacci]

Adding this back as an issue, since its original one was converted into stagnated PR #1466, but remains a pretty cool feature!

Original Issue Text:

Hey mapbox team! I first want to say I'm truly blown away by what you've built here. This is really, really impressive.

Anyhow, I'm curious to know if there is any interest in support non-mercator projections? I checked out the transformation logic and the projection appears to be hard-coded.

I'm sure there are optimizations to be had by assuming a single projection, but it would be really neat to be able to provide mapbox-gl with custom projection functions: not only would this enable other "common" map formats, but would open the door for some really creative visualizations (check out this and this).

It would also make mapbox-gl an ideal candidate for non-geo-based maps, like a cross-section of a human body with organs, circulatory system, nervous system, etc.

Thanks again for all the cool tech, and for developing in the open!

Cheers,
Mike

[ncammarata]

I'm really looking forward to this, and it's a bit of a blocker for using it in our project. We're using Mapbox for a data visualization, and everything is working smoothly with the exception of the unwanted Mercator projection.

Any tips of how to turn off manually would be much appreciated as well!

[mejackreed]

Support for a simple x,y coordinate system would also be great.

[dannybloe]

+100
We have so much geo-data living in different coordinate systems. Currently we are really trying to figure out how we can get them in mapbox-gl...

[tmcw]

To disambiguate this conversation, since it's floating in a familiar direction of indirection:

There are two things we talk about when we talk about projections:

Projections in data. This means you store data in coordinates that are not longitude and latitude, but instead meters or some other units. This is common for high-accuracy local data or state government data, and so on. This is what @dannybloe refers to, but it isn't what this ticket discusses. It's also a much simpler problem than the one this ticket discusses: if you upload data to Mapbox, it's reprojected automatically, and if you run it through a utility like ogr2ogr or reproject, it can easily be translated from any projection to any other projection.

Display projections. The kind you see and people argue about more, because opinions are like kittens. This is the thing this ticket discusses, and the much harder one, for a variety or reasons - the biggest one, in my opinion, being the lack of standardized scales and origins for display projections. And, for Mapbox GL JS, the ability to reproject data, deal with potentially non-square tiles, and so on and so forth. This is what this ticket discusses.

[mitch-besser]

I would like it to support custom projections. In other words, not just other standard projections, but also custom projections.

Google has this if that helps explain:

https://developers.google.com/maps/documentation/javascript/examples/map-projection-simple

[natew]

@tmcw thanks for insightful reply.

The two seem to go hand in hand actually, at least for our use case.

We basically enjoy quite a few features MapBox has (zoom, panTo, scrolling, etc etc) but also displaying a visualization thats not a map.

Given we don't want mercador projection, it would go hand in hand to also not have to convert all our data to lat/lng. So at least for the use case of flat projections, the data side seems naturally linked.

I could dedicate the next two weekends to implementing this.

Questions:

• Would that be useful / would I get help on getting a PR accepted if I do?
• Thoughts on implementing this? (difficulty, places to look in code, etc)

If it's not too large a task, this would be very much helpful for us and worth exploring very soon! Would be glad to dive into it.

[lucaswoj]

@natew We'd definitely be interested in working with you to put together & merge a PR that implements this functionality provided that this can be done in an elegant, backwards-compatible, and performance-neutral way.

As a first step, I'd suggest designing a public API using the RFC template: https://github.com/mapbox/mapbox-gl/blob/master/RFC_TEMPLATE.md

[pwilczynski]

Hey all! This issue is coming up a bit more for us, any thoughts on the future of projections in Mapbox GL JS? It's probably unique to our use case, but would love to hear more!

[vjpr]

Question: If I did use mapbox-gl-js to show a building floor plan (tiled or simply image overlay), and I wanted to show a marker at a specific X,Y coordinate from a reference point on the floor plan, can I transform thee X,Y plan-specific coordinates to lat, lng such that it will display correctly with mapbox-gl-js? Is this tricky or hacky, or can it be done elegantly?

Looks like this somewhat answers the first part of my question: http://wiki.openstreetmap.org/wiki/Zoom_levels

[anandthakker]

@vjpr so long as Mapbox GL JS does not support projections other than mercator, doing this will involve at least _some_ hackiness. Here's a blog post that describes how one can do this (and points to a utility library that may help): https://developmentseed.org/blog/2016/12/15/dirty-reprojectors/

[livemixlove]

It dawned on me this morning that you've created an excellent platform for optimized, zoomable, 2d interactive visualization! Support for cartesian coordinates would be dreamy!

[vjpr]

Would love some pointers from a maintainer about how to approach this.

[ArnaudLECUS]

Hi there. Is there something new about using non webmercator projection on Mapbox? I would like to use Ordnance survey raster maps with Mapbox, but they're available only with EPSG:27700 projection.

Looks like these files are concerned :

• https://github.com/mapbox/mapbox-gl-js/blob/master/src/geo/mercator_coordinate.js
• https://github.com/mapbox/mapbox-gl-js/blob/master/src/geo/transform.js
• https://github.com/mapbox/mapbox-gl-js/blob/master/src/util/tile_cover.js

But I'm not sure how to achieve this and I fear this is much more complicated. Does someone work on it?

[shiraleeana]

Just thought I'd chime in while researching both Mapbox and Carto support for non-Mercator projections. Here's Carto's documentation on the subject: https://carto.com/help/working-with-data/changing-map-projections/

[xawill]

Any news on this ?

[ryanhamley]

@xawill No updates on this issue at this time. It's still something we're actively thinking about and exploring, but it's not on our current timeline. Implementation of this is not trivial and we need to carefully consider the issue. It would be helpful for us to understand what use cases people have and what projections they're most interested in.

Also, we do have a work-around that may fit certain use cases. Check out https://github.com/developmentseed/dirty-reprojectors It has limitations but if you don't need a queryable map, it might satisfy your use case.

[xawill]

@ryanhamley Thanks a lot for the feedback and precisions.

My use case is to use a raster tiles (256x256px) dataset provided by the Swiss government. The coordinate system is EPSG:21781 (WMTSCapabilities.xml). The dataset is also available in WGS84, but not at the highest zoom level (10cm resolution), probably due to WGS84 conversion not being precise enough for the dataset to be useable. So for now, I am stuck at zoom level 21 or something.

Thank you for pointing out the workaround, but I had already checked it and it looks like it would not fit my use case, right ?

I am available to give you more info about my use case if needed, and even potentially available to help on the implementation of this improvement. I am not (yet) an expert on the topic, but I already learned a lot struggling with my own project and would be interested in learning even more.

[songololo]

It would be good to have some capacity for working with UTM zones.

[ryanhamley]

cc @chloekraw ☝️

Thank you for pointing out the workaround, but I had already checked it and it looks like it would not fit my use case, right ?

It's hard to say. I think you'd have to test it out and see. The library is based on a trick described in this blog post which uses the gdal_translate and ogr2ogr CLIs to manipulate the dataset. If you have the ability to manipulate the data and then create a tileset from the data, it _may_ work. But you wouldn't be able to accurately query coordinates and it would probably work best if used a bounding box to limit the view to Switzerland. I can't guarantee that will work as desired, but it could be worth a shot.

[rlueder]

@ryanhamley I'm not sure if you'd like to document use cases and projections of interest on this ticket but here are mine:

Use case
When mapping flight paths it'd be more useful to have them plotted as a straight line from point A to point B, similar to what is done with aeronautical charts (link below). This would also open up the possibility of using the GEO TIFF provided by the FAA and overlay those on a mapbox instance.

Projections
Lambert conformal conic
d3 Conic Equal Area

References
IFR Enroute Aeronautical Charts and Planning

[Shane98c]

We would be interested in GL-JS supporting non-mercator projections at the Polar Geospatial Center for pretty obvious reasons :). Our work on the poles has largely constrained us to using ESRI web mapping products because they so easily accept different projections.

[ryanhamley]

I'm not sure if you'd like to document use cases and projections of interest on this ticket

Yes! This is great. Thanks for sharing everyone. Feel free to continue posting use cases here. It will be helpful for us when assessing options in the future.

[Mike-Honey]

My interest is for projects focused on the Arctic and other polar regions, where mercator is most distorted.

The two options I'd like to use are:

1. Equal Area Conic e.g. d3 ref rlueder's post above, or similar. I expect this would be broadly useful for other scenarios where a more accurate rendering of area / distance is important

1. EPSG:3413 WGS 84 / NSIDC Sea Ice Polar Stereographic North. This is more specific to the Arctic perspective. https://nsidc.org/data/oib/epsg_3413.html.

[mejackreed]

My interest is for a simple x,y plane. Similar to Leaflet's L.CRS.Simple https://leafletjs.com/reference-1.5.0.html#crs-l-crs-simple.

I thought it might be useful to have Mapbox-gl-js as a similar type engine for WebGL interfaces.

[natew]

We had adapted it to display t-SNE maps where we needed to show many points
(>500k at times). So we synced it to a webgl point tenderer. Was actually
pretty nice and if we zoomed in a ton by default the projection didn’t
distort too much. But simple x y would work better.

[MattBlissett]

We at GBIF have used OpenLayers for EPSG:4326, 3575 and 3031 projections, examples at the bottom of the homepage: https://www.gbif.org/

The first projection is often used in scientific publications or for simple x-y diagrams, the polar projections for work at high latitudes.

Mapbox has better performance than OpenLayers, although I think the feature that ended up somewhat slower in OpenLayers (dragging the year slider and having points/polygons disappear depending on the value) is hardly used by users, so it's now much less important to us.

[PierreLacroix]

MapX (mapx.org) is the geospatial component of the UNEP "World Environment Situation Room" (former UNEP-Live), which is supporting all UNEP divisions as well as different conventions (Minamata, Stockholm, Biological Diversity, Ramsar...).
In MapX the interest is two-fold:

• polar projections for environmental applications at high latitudes
• projections such as Eckert for global views

[adamal]

1) Another vote for the use case of consuming non-mercator raster tiles. In Denmark, where I live and work, public map services are almost always available in EPSG:32632 or EPSG:25832. Only sometimes in Web Mercator.

2) In general, "local" projections seems to be better suited for locally relevant maps (both raster and vector), since they can go for maximum local accuracy without considering global accuracy.

3) With regards to 2) it would be very cool (as a feature even further into the future) to be able to seamlessly change between the best local projections when zooming in. Perhaps as a form of interpolation between web mercator and local projections.

[andrewharvey]

With regards to 2) it would be very cool (as a feature even further into the future) to be able to seamlessly change between the best local projections when zooming in. Perhaps as a form of interpolation between web mercator and local projections.

For a vector map wouldn't the "best local projection" always be an orthographic or perspective projection? It's only when you want to be able to have one big "flat" raster covering a large area that you need to sacrifice and pick another inferior projection.

[adamal]

For a vector map wouldn't the "best local projection" always be an orthographic or perspective projection

For high zoom levels, I would expect so. For medium zoom levels, I would expect some other projection to be better overall.

It's also intersting what Google Maps are now doing: They seamlessly transition from a spheroid Earth to a flat map.

[andrewharvey]

For high zoom levels, I would expect so. For medium zoom levels, I would expect some other projection to be better overall.

True, the globe view at low zooms wouldn't always be desirable.

[rlueder]

A use case for seamless transition between projections as suggested by @adamal for me would be a "world view" of active aircraft using web mercator and a conic equal area projection once a user has selected an aircraft and the map has zoomed into it. I could also see using bounding box values and not just zoom level to determine a switch between projections.

[ryanhamley]

Highly localized maps such as for construction sites or surveying often use specialized datums such as NAD83 in the US and Canada with a specific EPSG code for their localized region and unit of measure (m, ft, ftUS), so I could see applications for those sorts of clients (surveying, city zoning, construction mapping, drone maps) wanting to use local coordinate systems at high zoom levels.

[Svensl]

At UNEP we work both on global and local levels. It would indeed be great to have UTM projections as a minimum for some of our localized in country work.

[joseph-avenza]

I work at Avenza Systems Inc. and we are considering using MBGL in some of our solutions. Being able to display maps in their native coordinate systems is required for our purposes and we may be willing to commit some of our resources to developing this feature for MBGL. For our purposes, we would need to project base tiles and other vector data into the desired coordinate systems on-the-fly, though projecting raster data is not requirement.

The ticket above deals with MBGL JS but we would need to support this over multiple platforms (iOS, Android and QT). If I should create a new ticket else where please let me know.

[chloekraw]

Thanks everyone for all the feedback! Consolidating all requests here on this ticket, even though non-mercator projections would need to be implemented in mapbox-gl-native for iOS/Android/Qt/etc needs, is 👍

[tvogt]

Strongly support this request. I have a few maps where distortion is visible with the Mercator projection.

[joseph-avenza]

We would like to begin working on this as soon as possible, if it is a feasible request. I'd like to outline a rough approach I'm considering in hopes of getting help to gauge the feasibility and identify challenges:

• Abstract the projection classes so the developer can provide their own projection provider
• (For our purposes) Make a GDAL adapter to provide projections
• Add a translation layer between the vector tile cache and the renderer to project the tiles into the desired coordinate system on-the-fly (thus not requiring additional storage for each projection)
• Expand the clipping and bounds code to accommodate these new projections

Our goal is to have a tentative solution written in the next few weeks if possible. Any assistance from those familiar with the inner workings is greatly appreciated.

[ansis]

We would like to begin working on this as soon as possible, if it is a feasible request. I'd like to outline a rough approach I'm considering in hopes of getting help to gauge the feasibility and identify challenges:
...

Thanks for your interest in working on this! Can you explain in a bit more detail what specific use cases you are trying to solve. Thanks

[weinma]

Hi! I am working on a govermental project and it would be essential to view maps in another projections like utm. At the Moment we are evaluating the technology stack and mapbox seems to be a good choice but this feature would be a must.
So my qustion is, if you are considering realizing this feature the next few years?
(If you can say)
Best regards

[asheemmamoowala]

if you are considering realizing this feature the next few years?

This is on our long-term roadmap but not planned for this year.

[fxi]

What is the bottleneck that prevents implementing this feature ?

• Front end technical challenge ?
• Backend / Services / storage / incompatible specs ?
• Business side / lack of customers / funding ?
• Lack of interest from decision makers at mapbox ?
• All of that ?

How likely this would be a reality within the next year ? 0, 30, 50, 90 % ?

Projection is key in many fields: transport, environment, socio-economic, agriculture, health, forestry, climate, fishing, weather, risk assessment. Name one field that does not have its own requirements in projection system. Web Mercator was the one size-fit-all 15 years ago, but I think we should move away from it. Real cases do not need fancy hill shading generated on the fly client side. Even if that's very (very) impressive, it does not help visualize melting polar caps, electrical network, forest depletion, economic disparities, country development comparison, disease spreading, travel time computation/visualization, precision land registry mapping, mining concession boundaries mapping, large scale geological surveying...

I feel a huge gap between the effort in making this tool and services fast-and-fun and real professional use cases.

However, thanks for the fast-and-fun part : I use mapbox tools every day for the past 4 years and I'm still blown away by your tools... but projections.. I mean.. that would be great.

[Nate-Wessel]

Just in case we're still shy on use-cases, I'm interested in mapping ... Canada. A standard Mercator projection does not serve the country well at all.

[ansis]

@fxi thanks for your interest. The short answer is it would be quite a lot of work to do it right and it hasn’t been a priority.

Many parts of the renderer (actual rendering, tile selection, gestures, style specification) assume the world is a flat plane. Some of the changes necessary are straightforward but others are less clear. For example, how does changing the projection change what zoom means? zoom is currently heavily tied to mercator and has several different aspects: rendering scale, style evaluation, data loading & simplification. Each of those is impacted differently.

When we implement projections it’ll be important to do it right

[Mike-Honey]

@ansis I think you described a funding challenge. If funder(s) put in enough money to pay for the work (done right of course), then it could become "a priority"? If so, then that is a solvable problem.

[asheemmamoowala]

If funder(s) put in enough money to pay for the work (done right of course), then it could become "a priority"?

@Mike-Honey, Mapbox-GL-JS is part of an ecosystem of tools and technologies - including GL-Native (and corresponding Mobile SDKs), Mapbox Studio, the Style specification and the vector tile specification among others. While it may be solvable to put up a workable PR in this repo, moving on all these pieces together is what @ansis means when he says:

When we implement projections it’ll be important to do it right

[markeberhart]

I too have been pounding on this for years. Many individual organizations in both private industry and government have a real-world need to implement this right. I suggest we begin by looking at the challenges holistically across all of MBGL and, like any massive challenge, begin pecking away at it.

It seems to me there is a need, desire to change, as well as developers and money available.

A robust solution would allow for _any_ projection on _any_ planetary body, be it the Earth, Moon, Mars, etc.

@ansis If a team or individual wanted to begin working a solution, what would be the starting point? Where would MBGL want to begin?

[kzka90]

Interested in this too

[jorgejesus]

I am interested in this too, simply not using mapbox or being a client because it is only webmercator and I would need min EPSG:4326 and/or homolosine projection

[AliFlux]

I think a better idea would be to support a global ellipsoid canvas instead. Projections are messy, and localized for different regions. In my experience supporting WGS84 would be like a swiss army knife solution.

Just like Google Maps.

[marcelnormann]

I think a better idea would be to support a global ellipsoid canvas instead. Projections are messy, and localized for different regions. In my experience supporting WGS84 would be like a swiss army knife solution.

Just like Google Maps.

I strongly agree with @AliFlux ! All these projection related topics are headed to the past where maps have to be drawn on plane paper. There are established frameworks like OpenLayers or Leaflet to serve such use cases. Mapbox should keep heading to the future. For me it seems azimuthal projection (like in Google Maps above) is the most obvious projection for computer cartography.

[tvogt]

Except where it isn't. If you need a world map, then the globe doesn't just it. If you want a map of Russia or any other country that spans a large area, likewise.

I love that projection and that Google Maps moved to it as default. But it shouldn't be the only choice.

[alihcsumer]

Another work around is using openlayers raster reprojection capabilities. In the case of a mercator view and a non mercator layer, non mercator tiles are requested and by affinity transformation , a tile image in mercator projection is created. You can get a single tile image by in OL and set the GL texture in Mapbox. But it is way too hacky and dirty ! Working example https://jsfiddle.net/vw3oes9h/

[johnlaur]

+1 for an extremely desired feature that we have been following for years.

I was really hoping there would be at least a simple hack by now that reprojects mercator source data into a destination projection for display. Considering everything is already highly parallelized and rendered using WebGL, is this a viable option? I'm wondering if this is ever going to actually see the light of day, though. The fake albers projection data published a few months ago and the lack of interest by Mapbox on this issue's discussion doesn't really give me high confidence that this has a chance.

I also see a lot of argument here that appears to be people unwilling to settle for anything other than perfect end to end support for other projections. Please don't let perfect be the enemy of good. Like many of you following this issue, I'm just trying to show a map of Alaska (or pick your preferred northern/southern location) that doesn't look like junk.

[vulkd]

FWIW Here's some links related to workarounds / hacks for anyone Googling / needing more info:

• Previously mentioned by @johnlaur: https://www.mapbox.com/elections/albers-usa-projection-style, which links to the useful https://github.com/developmentseed/dirty-reprojectors
• The "Arctic Ice" implementation: https://blog.mapbox.com/mapping-arctic-sea-ice-in-a-polar-projection-a8fd68a03c53
• Which inspired me to try a Southern Ocean implementation, hopefully the terminology is correct: https://vulkd.com/articles/polar-projections-with-mapbox/

Note I couldn't get Spilhaus' projection to work using the above method so I assume not all projections work very well with Studio / mapbox-gl-js, or I probably stuffed up somewhere. 3D buildings still seem to work which is great

Will attempt to edit this as new methods / implementations come up

[Mike-Honey]

Realistically, given the recent news, we should abandon any hope of this ever being implemented in mapbox gl js v1, or any community-led fork.

https://joemorrison.medium.com/death-of-an-open-source-business-model-62bc227a7e9b

[mourner]

@johnlaur

[ppeduzzi]

Hello,
I work for International Organization, supporting countries at governmental level, also supporting Multilateral Environmental Agreements.
Having Mercator projection where Greenland is the size of Africa is distorting the vision of the world. I understand the technical rational for this and for rapid/smooth navigation (vs reprojection of tiles on the fly), but frankly, this is no longer defendable, in my daily working life for 3 reasons:

1. When working with developing countries in the South, the use of Mercator is felt like a way to artificially increase the importance of the Northern countries. I'm not asking for Gall-Peters or Waterman Butterfly, but a simple Robinson or Mollweide would be great to have.
2. When mapping environmental issues, the conservation of area (e.g. for mapping deforestation, forest fires, desiccation of lakes and sea (e.g. Aral sea), urbanisation) is more important than keeping the angles. Again having Mollweide projection would be a great asset.
3. When dealing with polar issues, such as for mapping loss of Arctic Sea Ice extent, or Antarctic Ozone hole layer recovery, doing this under Mercator is really not appropriate. A polar projection, or a globe, would be great.
   I hope that MapBox can solve this, I'm sure that with the skills of someone like Vladimir Agofonkin, this is something that can be cracked easily!
   Thank you for your consideration.

[markeberhart]

@ppeduzzi I could not agree more. If a user is visualizing Mapbox via WebGL as 2.5D or 3D, lat/lon, height (zoom), and the pitch/roll and yaw can be controlled programmatically, and that's awesome because it allows for a certain level of country size & distortion to be minimized. That said, it is not enough for areas in extreme north and south like Greenland. Unless Mapbox were to support a spheroid-based model like Google Maps (as mentioned by @marcelnormann).

There is a desperate need to offer libraries/code to simplify the process of encoding WGS-84 (un-projected data) in any standard projection, while supporting the vector tiles standard and Mapbox style sheets. Echoing @johnlaur It doesn't even have to be _any projection_, but simply rolling out support over time for commonly-needed projections such as polar arctic/antarctic and a few extreme latitudes.

I've looked at @mourner code closely and it is fantastic, just amazing work and been very helpful in so many ways to so many. If it were possible to create usable vector tile files and have them simply follow a projection other than EPSG:3857, it would vastly increase the adoption of Mapbox as a platform in general.

I should add that some of us (myself included) have been asking for alternate projections since before WebGL was the most common Mapbox plugin (I believe my first comment on it was in 2016) - In the end, it's really about visualizing the Earth correctly. If Mapbox can make that happen for the most critical areas, it's not really that important _how_ they do it, so long as it gets done in one way or another- hopefully open source :)

[ppeduzzi]

@marcelnormann and @AliFlux, indeed having a global ellipsoid could resolve many things, including looking at polar areas. However, in such globe view, half of the world is hidden. Hence this is not appropriate for comparing countries across the world. For many applications we still need a good projection (respecting areas) to provide a synoptic view of the world. However, one does not exclude the other option ! Check: https://earth.nullschool.net/#current/wind/surface/level/orthographic=-350.01,67.46,455
and
https://earth.nullschool.net/#current/wind/surface/level/winkel3
Of course, this application is not facing the same challenges as MapBox, (with tiles) but the reprojection on the fly is very fast.

[MattBlissett]

GBIF is also an international organization, and faced similar issues. We liked the performance of MapBox-GL-JS, but couldn't compromise on the projections we require.

Our default maps are still raster tiles (e.g. bottom of GBIF.org, click the globe to change projection), but these are generated from vector tiles produced using a modification of OpenMapTiles. They're shown using OpenLayers, which has decent support for different projections. At the time, performance in OpenLayers for vector tiles (except for Web Mercator) was poor, but there have been efforts to improve that, so it might be acceptable by now.

[emb-lautec]

We are developing software for onshore and offshore construction and was planning on using Mapbox GL JS heavily in the following years but not supporting non-mercator projections is a deal breaker on the long run as there are to many usecases where webmercator is not ideal in the construction industry. This will definetly force us to move away from Mapbox GL JS v2 into other frameworks like Openlayers.

I understand that there is a high level of compelxity involved here as well as other priorities. Could you at least give an indication of whether this is in the pipeline and if so in which year? This would provide us the comfort to keep relying on Mapbox GL JS v2 which is a great framework in any other sense.

Thanks.

[mathiash98]

I would like to pitch in as well.
We develop a mainly offshore solution for vessels where we use the General Arrangement (image of the vessel with all it's rooms) as background and put markers on top using x and y coordinates. This has been done using Leaflet's CRS.Simple. https://leafletjs.com/examples/crs-simple/crs-simple.html

Our newest product aims to combine world map data with local vessel data on the same webpage, so it would be great to be able to use the same mapping tool for both maps.

• Sadly Leaflet has limited support for the custom styling we use from Mapbox. So we might end up needing both Leaflet and Mapbox Gl