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

2. 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?

[c4b4d4]

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.