Incorrect bounds for EPSG:3857

[petrsloup]

https://epsg.io/3857

Projected bounds: -20026376.39 -20048966.10 20026376.39 20048966.10

It should be 6378137 * PI: -20037508.34, -20037508.34, 20037508.34, 20037508.34

[jratike80]

The bounds are now given as

Projected bounds:
-20037508.34 -20048966.1
20037508.34 20048966.1
WGS84 bounds:
-180.0 -85.06
180.0 85.06

I believe they are correct and take into account the clipping near the polar areas. So the issue could be closed.

[mvlcek]

The x coordinates are now ok. However, the most important use of this coordinate system is tiling and for this use the y coordinate is cut off at 85.051129° = 20037508.34 to give square tiles (see https://en.wikipedia.org/wiki/Web_Mercator_projection, https://wiki.osgeo.org/wiki/Tile_Map_Service_Specification#global-mercator, etc.)

Any other bound would be arbitrary, unless you link it to a maximum projection error.

[jratike80]

The most official source is the EPSG registry https://epsg.org/crs_3857/WGS-84-Pseudo-Mercator.html? and there the extent is reported to be World between 85.06°S and 85.06°N. with a remark:

Web map tile service latitude limit is +/- 85.05112878°.

The remark is missing from epsg.io but I do not see any reason to use any other extent than what EPSG/IOGP is using.

[mvlcek]

As I mentioned, any latitude bound is arbitrary, as there is no real reason to limit usage to 85.06° - it just cannot be 90°. On the other hand, on a website from maptiler, where the main business is tiled maps in pseudo-mercator, I would expect the bounds to be those of the standard tile services, and then maybe a comment that these bounds may be extended for non-tile-based functionality.

Regards from a twice-burned victim of wrong (longitude) and misleading (latitude) data from epsg.io, when trying to calculate tile coordinates.

[jratike80]

The reason why epsg.io exists is the same as for the predecessor https://spatialreference.org/about/

to allow you to use URL/URI-based references to spatial reference systems

epsg.io does not use custom EPSG definitions. It proxies the official EPSG data through more user friendly services. Nowadays also the official EPSG site supports direct links but the service is still not super easy to use. This is for the CRS EPSG:3857 https://epsg.org/crs/gml/id/3857/export?format=gml and this is for the valid area of EPSG:3857 https://epsg.org/api/v1/Extent/3544/export?format=gml

The limit of 85.06° may be arbitrary but the folks at IOGP have decided that is the value that they want to have in their standard. The name of the CRS cannot be EPSG:3857 if the metadata, including the bounds, are not those defined by EPSG.

I see that the the export of EPSG:3857 bounds from the service of epsg.org does not include the remarks about the limits used in WMTS services https://epsg.org/api/v1/Extent/3544/export?format=gml

You may want to create an issue in https://epsg.org/contact.html and ask why the remark: Web map tile service latitude limit is +/- 85.05112878° does not appear in the export and if that could be added in some way to the data. Maybe they will tell you that because their extent is larger than the extent of the tiling scheme then everything is OK from their perspective and that users should know what tiling schema they are using.

I noticed also that when the WMTS standard defines a predefined "Definition of Well-known scale set GoogleMapsCompatible" in table E.4 it does not mention what should be the TopLeftCorner of the matrix set and that there is a difference to the area of validity as it is defined for EPSG:3857. However, it is defined in another OGC standard https://docs.opengeospatial.org/is/13-082r2/13-082r2.html. That is not most friendly for the users either.

So there is a reason for your annoyance but the right solution is not to fiddle with the area of use bounds in epsg.io site. Maybe including the remark as it appears in the extent details in https://epsg.org/crs_3857/WGS-84-Pseudo-Mercator.html? would be easiest fix but I don't understand where to find that remark from the EPSG data exports.

[mvlcek]

The remark should be in https://epsg.org/api/v1/Extent/3544/export?format=gml, which defines the bounds linked from https://epsg.org/api/v1/Extent/3544/export?format=gml, but sadly it isn't.

However, this extent file is inconsistent itself, as while the bounds are defined as +/-85.06, the bounding polygon uses +/-85.05113.

It would be nice to have the comment on epsg.io, too, but if it is just a different view on the data exported from epsg.org and the remark is not exported, than I suppose nothing can be done.

It would be nice, if epsg.io could add additional remarks to the coordinate systems to help other users to avoid the problems, I had.

[jackchoumine]

Any other bound would be arbitrary, unless you link it to a maximum projection error.

Hi why it 85? I calc that is 71.57.

My method TANa = PI*R/R = PI = 3.1415 SO a = 71.57. why my result is not same.