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.

[mike-marcacci]

This looks amazing! Great work! 🙌

[eivsal]

Great work! Is there any chance of added support for transverse mercator projections? We are specifically looking for support for either ETRS89 or WGS84 over Europe.

[mourner]

@eivsal we're looking into supporting UTM projections in the future, but it might be difficult due to how heavily distorted they get outside of the targeted range. Meanwhile, for Europe, I'd recommend either Lambert conformal conic (recommended by European Environment Agency and INSPIRE for Europe) or Albers equal-area conic. center: [0, 52], parallels: [35, 65] in options for both.

[eivsal]

@mourner Thanks for reply 💯

[AliFlux]

Oh wow! Can't wait to see how terrain looks like in custom projection. ⚡⚡

[johnlaur]

To @ansis @mourner and all who worked on this feature, thank you very much!

Is there any easy possibility to specify that the reprojection "wrap" on a meridian other than the antemeridian? This would be particularly useful to improve maps of Alaska which otherwise suffer from this nearby edge:

{ //EPSG 102006: Alaska Albers Equal Area Conic 
  name: "albers",
  center: [-154, 50],
  parallels: [55, 65],
}

[mourner]

@johnlaur not currently, but this is a really good point and something we want to address in the future — opened an issue for it: #11180.

@AliFlux terrain is not supported on alternate-projected maps in the initial release, but we're exploring ways to enable this in follow-up releases.

[Mike-Honey]

Is there any hope of this feature making it out into the Power BI Custom Visual integration? If not please tell us now so we can work on alternatives.

[JoshData]

Great work here. I'm using the Albers projection now at https://www.govtrack.us/congress/members/map and https://www.govtrack.us/congress/members/OR/4 and similar pages, and it feels good to be able to use an equal-area projection.

Some feedback that I hope is useful (all with respect to the Albers projection):

• Zooming in on locations above the north pole when the map is centered in America, the map actually restores to an upside-down web mercator.
• The data type expected for the Albers center property is an array, but a Point could be more in line with the rest of the API.
• There are some panning glitches. When I move too close to the "left" side of 180 degrees (i.e. above the north pole when centered on America), it jumps to the "right" side of 180 degrees.
• It seems like the Albers center property's latitute actually may not be needed. The value does affect the map, but it seems to somehow affect the map's scale, which doesn't seem intentional. Looking at the Albers definition on Wikipedia, I think it only affects the 'center' of the projection space, but that's arbitrary anyway. Replacing center with reference_longitude (or just longitude to be parallel to parallels) might be cleaner.

It would also be very interesting (and this is just a fun thought) if the reference longitude changed dynamically based on panning, so that the map's center was always the reference center of the projection. The reference latitudes (parallels) could also change while maintaining a fixed separation. This would eliminate the distortion and rotation you get when panning on an actual Albers projection (and it would reduce the number of projection parameters to just one parameter, the separation between the reference latitudes). But I recognize that this might be... a bit difficult.

Thanks again.

[benstadin]

Interesting. But... Does it mean when you zoom in the map will always be projected to Web Mercator? Hm. One reason for using a selective map projection is precision, not just for the looks of it when zoomed out.

Anyways, congrats. This is technically very interesting.

[marcelnormann]

Interesting. But... Does it mean when you zoom in the map will always be projected to Web Mercator? Hm. One reason for using a selective map projection is precision, not just for the looks of it when zoomed out.

I agree. I would prefer the opposite way: Having local projections and when zooming out, slowly migration to Web Mercator. IMHO global projections are for gourmets (unless you are interested in areas close to the poles), while local projections are what most people are interested in or are forced to use.

[ynte]

I was really hoping to be able to use custom local projections / coordinate systems. EPSG:29882 in my case. I'll still have to stay with Leaflet for the foreseeable future then.

[GetecHarry]

Firstly nice work, this is really cool! Unfortunately it doesn't help my use case. As @mathiash98 mentioned, the ability to use a simple CRS like Leaflet JS would be amazing! Whilst i know that Mapbox is built primarily to display a world map, the tool is much more powerful than just that and I've had success using it with custom map tiles generated from drawings for example. The only thing is I've had to run custom co-ordinate conversions because of the mercator projection.

[mourner]

@benstadin @marcelnormann this would defy the purpose of using projections on an interactive map.

All map projections are a way to flatten the globe onto the screen while trying to find a balance between three types of distortion — of relative sizes, distances, or shapes of geographic objects. Mercator is fantastic at higher zoom levels, because it's conformal — preserving shapes, local angles between lines, and local directions (up is north, down is south), making it the best projection for navigation on a city-level. Its biggest shortcoming comes out on low zoom levels — since it severely inflates sizes of objects the closer they are to the poles, when you have a big range of latitudes on one screen, relative sizes are very misleading. For example, Greenland looks the same size as Africa, even though it's actually 14 (!) times smaller.

GL JS projections were designed to minimize distortion across all zoom levels in an interactive context. This means you can choose the best projection for your use case on low zooms, be it a world projection like Natural Earth for thematic mapping, or a conic projection like Albers or Lambert that's configurable for a specific range of longitudes and latitudes (best for minimizing distortion on a specific continent / country level), and then have GL JS gently transition to Mercator on higher zooms so that it's usable for city-level mapping, and shapes of roads and buildings are not diagonally squished in a weird way.

This may be an unusual approach for a GIS professional used to traditional maps, but it's a rare attempt at reimagining projections for the interactive maps era from the ground up, and you might warm up to it if you actually try it in practice.

As for specific projections that are not yet supported — stay tuned, we'll listen to your feedback very closely when deciding how to expand the feature in future releases.

[timrobertson100]

Congratulations on some really amazing work here folks.

Could you comment if you ever foresee supporting user-supplied tiles in different projections, please? e.g. equivalent of this OpenLayers example.

[mourner]

• The data type expected for the Albers center property is an array, but a Point could be more in line with the rest of the API.

@JoshData This is because it's a part of the style specification, so it has to be strict JSON.

• It seems like the Albers center property's latitute actually may not be needed.

Latitude is officially a part of the parameters for the Albers projection (e.g. as described on Wikipedia), so we kept it and used a generic center property for simplicity and consistency with other projections.

Could you comment if you ever foresee supporting user-supplied tiles in different projections, please? e.g. equivalent of this OpenLayers example.

@timrobertson100 This is technically possible to implement in the future, but there are no plans for this in the short-term as far as I know. Our bet was on reprojecting from Mercator since most of our existing services and tooling are built around it, and we wanted to introduce projections in a way that's 100% compatible with existing Mapbox tilesets.

[benstadin]

@mourner I respectfully disagree that projections are not practically relevant for high zoom levels. I'm not false advertising our product at this place, but our proprietary 3D (or 2.5D) vector map rendering engine supports those projections for good reasons and due to customer demands. Thus I'm a bit surprised by the statement that a zoomed out non-mercator map is good (a nice feature indeed and technically interesting), while a zoomed-in non-mercator map has rare practical use. And that approach somehow "reimagines" maps.

We usually use UTM projections for e.g. city, fair ground or shop floor navigation where a mercator map does often not provide acceptable results - even for very small areas (think of shelves inside a shop). It means on a technical side of things some challenges for projection-agnostic indexing and processing for our vector tiles storage.

We also use Mapbox maps for some projects, mostly where we just need an outdoor map. For projects where precise mapping or indoor mapping is required we either use our own technology, or another map framework that supports projections. These maps are not for GIS professionals but for actual end users who otherwise often complain. As another example, telling map app users or customers to print out their campus or building maps in less precise / distorted web mercator to make them match to the distortion of the map in an app when zoomed in is also not an option.

In the end the only truth is in the ball shaped globe ;-).

[mourner]

@benstadin please excuse me for my ignorance on the topic of high-precision indoor maps, but aren't you conflating two concepts here — display projection, and coordinate (e.g. datum) mismatch between datasets? If coordinates of your data are transformed properly for overlaying on a Web Mercator map, I believe the latter can be used well even for highly detailed (mm-precision) maps given high enough max zoom and vector tile extent.

To be able to represent detailed local data without distorting shapes, a projection has to be conformal — meaning having constant local scale in every direction around one point, and preserving relative angles. Web Mercator is slightly non-conformal due to spherical math applied to ellipsoidal (WGS84) datum, and this deviation is well documented — reaching at max ~0.67% distortion for local scale in N/S direction, and ~0.1% distortion for local angles (both at equator). This kind of distortion may be important for GIS analysis, but it's pretty much imperceptible to the human eye when used for display purposes. So I'm really surprised to hear that users complain about Web Mercator distortion of their campus or building maps — perhaps a concrete illustration would be helpful here? What am I missing?

[tvogt]

It works brilliantly, thanks a lot!

One thing I noticed is that the calculation of region bounds seems to not apply correctly, i.e. options.bounds values which work on Mercator projection are too narrow on naturalEarth, for example, cutting off the edges of the region.

[stepankuzmin]

One thing I noticed is that the calculation of region bounds seems to not apply correctly, i.e. options.bounds values which work on Mercator projection are too narrow on naturalEarth, for example, cutting off the edges of the region.

This may be related to #10064

[benstadin]

@mourner No, I do not talk about data mismatches or any other technical aspect at all. These are solved problems.

It's different projections and different maps with different looks for certain use cases. I understand that indoor or venue mapping is not the targeted audience for MapBox. I just wanted to keep the record straight that such maps are not just used to look at them when zoomed out for esoteric reasons, but find actual practical use in application where, to quite the contrary, it's about rather small areas like campus sites or fair grounds.

[kreativejuices]

Is there any plans for enabling the use of maps that are Ordnance survey raster maps with Mapbox, but they're available only with EPSG:27700 projection?

[matthias-ccri]

We also need accurate projections at higher zoom levels. For us, Mapbox GL is not the main mapping library; we just use it to render vector tiles for base layers. We plot the other layers in EPSG:4326 (aka WGS84 / equirectangular) and we need the points to line up with the base layer. Unfortunately since the Mapbox renderer doesn't preserve the equirectangular projection at all zoom levels, we can't use it. Instead we have to use the webmercator projection and add a postprocessing step to "squish" the raster.

[exotfboy]

Hi, I'd like to know how does mapbox support no-mercator projection:

1 The vector tiles are generated with mercator projection, and mapbox-gl-js support other projections by reproject the tile on the fly during client rendering.

2 The vector tile are generated with no-mercator projection, and mapbox-gl-js render them as they are without any reprojectiong.

[mourner]

@exotfboy it's the first; you can read about the way projections are implemented in GL JS in detail in this blog post: https://www.mapbox.com/blog/adaptive-projections

[exotfboy]

@mourner Thank you.

[barbaramartina]

Hi all, do you know if the mobile SDKs are also supporting non-mercator projections for vector tiles? What about raster tiles?

[mariochermes]

I would also like to know this.

Hi all, do you know if the mobile SDKs are also supporting non-mercator projections for vector tiles? What about raster tiles?