Support multiple projections

[markeberhart]

It would be great if this could support multiple projections- especially 4326 (equirectangular), or allow for creating a custom CRS like we can in Leaflet.

[markeberhart]

@mourner how hard would this be to implement? I'm most curious about where 3857 is most tightly tied into the code and whether (for starters) we could have Proj4Js or the like take care of performing point conversions and expand support from EPSG3857 to also include EPSG4326.

[mourner]

@markeberhart it's likely not hard but if you limit the projections to only those that conform to invariants that 1) zoom scales logarithmically, doubling with each level, 2) you start with z0 tile and can get four z1 tiles by splitting the previous tile, and so on.

[markeberhart]

@mourner yeah, that's the trick with 4326 is that instead of Z0 starting with 1 tile (eg 256x256), you start with 2x tiles at Z0 (1 for each hemisphere). It's not a huge problem, as everything is relatively the same, but the calculations are a bit different due to the map always being twice as wide as it is high.

by the way- thanks for all you do to bring mapping into 21st century!

[anandthakker]

@mourner Related to mapbox/mapbox-gl-js#1466, I'd like to work up a PR to add support for providing custom projection function satisfying the two assumptions you mentioned above, which I understand to mean that zoom level z must be a square 2^z by 2^z grid of tiles.

Proposed change:

• Accept options.projection, which is just a function w/ signature ([lng, lat]) => [x, y]. This function should project a lnglat point into a point in [0, 1] x [0, 1], as these normalized coordinates are then transformed into the appropriate tile coordinates based on zoom level here.
• Pass that option through to convert, convertFeature, project, projectPoint, and use it if present (defaulting to the existing web mercator impl if not)

This won't solve @markeberhart 's use case -- at least not directly -- but it would at least lay some ground work for the trickier work that that would require.

[markeberhart]

@anandthakker @mourner This is a great start. It does seem to pretty-much be teh same discussion as #WIP - support for non-mercator projections #1466

From a UI standpoint, if Mapbox/Leaflet had multiple projections "loaded" (using that term loosely), Mapbox/Leaflet could have a UI element that gently suggests another projection to the user once they have entered an area (?defined by a bbox to a projection?) that would be better presented with an alternate projection. This could eliminate jarring visual changes between projections. It might also educate users on how important the right projection is (such as areas with extreme latitudes).

Took a screen grab from the Mapbox gallery (https://www.mapbox.com/gallery/#map-12) and "added" a conceptualization for a UI element that would show potential projections available based on user interaction and available projections.

While this is just a concept, it represents how great it would be if we could expose an interface that allowed developers the ability to empower users to switch between projections based on their location in a map.

[diegotorresd]

I was able to make geojson-vt support EPSG:4326 by simply changing the projectPoint() function, in case anyone is interested: here it is
Only tested for my (very specific) use case, so YMMV.

[markeberhart]

I had to apply a custom CRS to my map as follows using proj4js. Still dealing with hemispheres overlapping. I'm certainly no expert here- just trying to get the job done :)

Thanks for the help so far from everyone, I'm almost there!!

var crs4326 = new L.Proj.CRS.TMS('EPSG:4326',
                "+proj=longlat +ellps=WGS84 +datum=WGS84 +no_defs",
                [-180.00, -90, 180.0, 90], /*minx,miny,maxx,maxy*/
                {
                       resolutions: [
                0.7031250000000000000000000,
                0.3515625000000000000000000,
                0.1757812500000000000000000,
                0.0878906250000000000000000,
                0.0439453125000000000000000,
                0.0219726562500000000000000,
                0.0109863281250000000000000,
                0.0054931640625000000000000,
                0.0027465820312500000000000,
                0.0013732910156250000000000,
                0.0006866455078125000000000,
                0.0003433227539062500000000,
                0.0001716613769531250000000,
                0.0000858306884765625000000,
                0.0000429153442382812500000
                       ]
                });

[codenamezjames]

Did anyone ever figure this out? I am making a seat map (like you might find in a theater or stadium) and i want to use a flat projection similar to ZOOMIFY

[toams69]

Any update on this one?
I would like to use this in a specifiq projection

[jamesurobertson]

Are there any plans for this issue?

[DrPDash]

Any update on this, folks? We really need this support for other CRS, especially EPSG:4326. I got the L.vectogrid to work nicely for large GeoJSON files with popups on a test page with EPSG:3857. As soon as I tried to get to the real project application (with EPSG 4326), I realized it does not support it. Thanks.

[SnailBones]

@prasanjitdash Would you be interested in submitting a PR for this?

[DrPDash]

@SnailBones thanks. I am not very familiar with PR (sadly, I still have some basic technological learning curve ahead of me). Does this mean I simply open a request or does it mean I will provide a modified code for verification that if approved will be merged?

Anyways, when I have some bandwidth, I will certainly dig into this (2022). Currently, for my needs related to coastal applications using satellite, in situ, and socio-economic data, I ended up generating MVT rather than using GeoJSON directly. This works well for scaling and for large GeoJSON/shapefile over 1 GB in size.

[SnailBones]

Thanks @prasanjitdash! A PR or pull request is indeed submitting modified code to be approved and merged after discussion. There's a closed PR here that's an attempt at solving this issue and might be helpful to look at if you do decide you'd like to tackle this.

This would be a cool feature to see, particularly with the recent introduction of new projections to Mapbox GL JS. But I'm glad you found a workaround with MVT!