LeafletJS – Why Conversion Fails When Re-projecting to Spherical Mercator

coordinate systemleafletmapbox

When I use the Mapbox Leaflet pre-packaged Projection class SphericalMercator to project a lat/long coordinate into EPSG:3857 I have to multiply the result Leaflet provides by the earth's radius.

var latlng = L.latLng(45, -120);
var sphericalMercator = L.Projection.SphericalMercator.project(latlng);

The following is what Leaflet returns:

sperhicalMercator.x => -2.0943951023931953
sphericalMercator.y => 0.8813735870195429

But the actual answer is (-13358338.8952, 5621521.48619), which I got by multiplying the results returned by Leaflet by 6,378,137 (earth's radius in meters).

var actualAnswerX = sphericalMercator.x * 6378137;
var actualAnswerY = sphericalMercator.y * 6378137;

Am I missing something?

Best Answer

This has been fixed in Leaflet after the 0.7.2 release.

Related Solutions

MapServer – Why MapServer Adds Horizontal Artifacts When Projecting EPSG:4326 Data to EPSG:3857

Your question implies that the problem doesn't occur when the data isn't projected. Is this the case?

It looks like the issue is with features that cross the -180 / +180 meridian. The problem arises when the GIS assumes that the west boundary of the polygon has a lower X ordinate than the east boundary, but in these cases this is reversed.

The problem isn't specific to MapServer and I expect you would see the same issue in any GIS software.

One way to address this sticky problem is to split these polygons over the meridian, so that the east side of the feature displays on the west of the map and the west side of the polygon is on the east side of the map.

[GIS] Why is the Google Maps circle shape not matching to the distance calculated with PostgreSQL

~~I suspect the issue relates to the very real difference existing between geometry objects, existing on a plane map surface, and geography objects, existing on a curved globe surface.~~

It is always more accurate (but slower) to do calculations with geography types on a globe. Projecting features from a globe onto a plane always incurs distortion.

Looking at your SQL code, on the 3rd line you do cast to geography but for the "incomplete" reasons. You do it to use meters instead of degrees for the distance measure, and that is good. You should also do it because you get more accurate results.

Now, in the 1st line of your SQL code, you make a point out of coordinate parameters, but it is by default a geometry and so you end up not comparing like with like. Try casting the point you make to geography and see what happens.

Like this, i think:

ST_SetSRID(ST_MakePoint($1, $2),4326)::geography

If you draw circles using GMaps, they are probably not representing true circles on the globe. If "GMaps" (not sure what you mean, exactly) uses the Web Mercator projection, then a drawn circle really represents an "egg" shape on the globe, with the pointed end up north. That's how the Mercator projection distorts things -- things get hugely stretched as one moves away from the equator.

Best Answer

Related Solutions

MapServer – Why MapServer Adds Horizontal Artifacts When Projecting EPSG:4326 Data to EPSG:3857

[GIS] Why is the Google Maps circle shape not matching to the distance calculated with PostgreSQL

Related Question