We have some data that is stored in GeoJSON format (using EPSG:4326), but now we want to display the data in the mapbox-gl-js, which only supports EPSG:3857 for display (support for other projections is not yet implemented). The data is arbitrary, non-earth geographic data.

How can I transform the coordinates from the old system, so that visually map in both systems look identical?

I do not care about actual geographical accuracy, but rather the visual accuracy.

As I understand, I should be working with Secant Projection but to me it just doesn't seem to work.

closed as unclear what you're asking by Vince, Jochen Schwarze, xunilk, csk, Dan C Feb 21 at 17:01

Please clarify your specific problem or add additional details to highlight exactly what you need. As it's currently written, it’s hard to tell exactly what you're asking. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • 3
    This sounds like a XY problem - why are you sure your "system" support EPSG:3857 only? – IvanSanchez Feb 4 at 19:48
  • 3
    You can't achieve conformal result between geographic and Web Mercator. They are both non-conformal in different ways. – Vince Feb 5 at 0:13
  • > This sounds like a XY problem - why are you sure your "system" support EPSG:3857 only? Yes, it does only support EPSG:3857. It's the mapbox-gl-js, and they have an issue open to support other projections - github.com/mapbox/mapbox-gl-js/issues/3184 – Justas Brazauskas Feb 5 at 14:29
  • And what format is the data in? GeoJSON? shapefile? something else? – IvanSanchez Feb 5 at 18:36
  • Yeah, the data is in GeoJSON format – Justas Brazauskas Feb 5 at 21:13

Assuming that your system really only supports EPSG:3857. That is, the Y answer:

You know that the world looks like a rectangle when rendered in EPSG:4326. A rectangle whose width is twice as high. You also know that the world (more precisely a part of it) looks like a square when rendered in EPSG:3857.

Therefore (leaving aside the distortion of the world to the equirectangular projection) you should make a small sacrifice if you want to see a rectangle as a square, and that in turn the geometries within it will not deform. The first option involves losing all the geometries that are at longitudes less than -90 or greater than 90. The second option is to create vast oceans at the poles. Being the second option less destructive, I will opt for it.

Beyond the choice, the only way you have is to transform the coordinates of all the vertices of your geometries. But transform them in an inverse way to how they transform when projecting in Web Mercator. So then, when transformed by the projection, keep the relation they had originally, prior to any process.

The way in which the meridians are rendered in EPSG:4326 and EPSG:3857 is the same (straight, vertical and equidistant lines), so you will only transform the latitude of each pair of coordinates.

When projecting the latitudes to the y coordinate of web mercator, the following transformation takes place:

y = R * LN( TAN( ( PI() / 4 ) + ( phi / 2 )))

Where R = 6378137 is the radius of the sphere, in meters; and phi is the latitude, in radians. We are not going to worry about the radius, because it will be multiplied when projecting. But yes for the radians, because our input are decimal degrees and our output must be decimal degrees as well. Otherwise, we will apply the inverse transformation.

newlatitude = ( 2 * ATAN( EXP( latitude * PI() / 180 )) - ( PI() / 2 )) * 180 / PI()

Where latitude is the original latitude coordinate and newlatitude is the transformed one, both in decimal degrees.

For example, we can have as input a square of 10 degrees wide by 10 degrees high, right? No! In the world, meridians are not equidistant straight lines and that is not a square! Ok, but we see that shape as a square when rendered in EPSG:4326? Yes. Well, if we transform its latitude before projecting it in web mercator, we can continue to see it as a square in that projection.

  • This is exactly what I've been looking for. Thanks! – Justas Brazauskas Feb 6 at 10:12

This is not the best system architecture, because it requires some dirty reprojections, but I suggest...

Reproject the file using ogr2ogr, forcing the input and output SRSs

ogr2ogr is my go-to projection swiss-army knife, and can handle weird reprojections and manually force SRS/CRS/geoid changes. It's part of the GDAL utilities, and readily available in any Linux distro.

So I've imported this cat into a QGIS project via DXF. Note how the CRS is EPSG:4326, as noted in the lower-right corner:

cat in qgis

The cat's coordinates span from 0,0 to about 150,-150, as can be seen in the GeoJSON file. There is an obvious distortion when displaying this data in EPSG:3857:

cat in geojson

And now I run the magic ogr2ogr command in a console:

ogr2ogr -s_srs epsg:3857 -t_srs epsg:4326 kitten-projected.geojson kitten.geojson

The most important bit here is -s_srs epsg:3857. It means "forget about the fact that geojson files are implicitly in EPSG:4326, I'm very sure my input data is in epsg:3857". Then the target SRS, and the destination and source filenames.

And now I can display my cat again:

projected kitten in geojson

Note several things:

  • The cat's coordinates now refer to meters (because EPSG:3857 units are expressed in meters, vertical units being accurate only at the equator). See the length of the scale bar here.
  • No handling of numbers anywhere. ogr2ogr has done all the heavy lifting here.
  • The cat now lives in Null Island, as that is the origin of coordinates for EPSG:3857 and it doesn't span a large area when its coordinates refer to meters.

Also keep in mind that mapbox-gl will probably have a maximum extent for the map, covering from -2million,-2million to +2million,+2million in EPSG:3857 coordinates. Any data with coordinates outside that might get clipped.

  • It's a good approach! There could be a small spheric world (R=57.29577951) in which each great circle measured 360 meters long. Considering that the kitten was represented in a mercator projection of that world, I think that the difference between meters and degrees could be avoided. We should try to save the definition of that projection +proj=merc +R=57.29577951 +units=m +no_defs) in a text file (i.e., kittenworld.txt) and then: ogr2ogr -s_srs kittenworld.txt -t_srs epsg:4326 kitten-projected.geojson kitten.geojson. – Gabriel De Luca Feb 6 at 13:17
  • Or scale up the original data (which I could do via inkscape). Since the OP didn't provide information about that, I cannot make any suggestions. – IvanSanchez Feb 6 at 13:42

Not the answer you're looking for? Browse other questions tagged or ask your own question.