2 questions: "confusion about EPSG:900913" and "performance of Equirectangular projection"

[ji-podhead]

Equirectangular projection
wouldnt it be better for planar projection/map to use Equirectangular coordinates:? this could even spare unnesscesary computation in spherical mode with a increased zoom/low fov by switching to planatary.
by switching to non-spherical coordinates i dont need to to convert and remap/interpolate the spherical coordinates for every single vertex of every element that i want to place/find on the planatary map.
->
"x = r λ cos(φ0)
y = r φ
This is simple equirectangular projection.In most cases, you'll be able to compute cos(φ0) only once, which makes subsequent computations of large numbers of points really cheap."

---

EPSG:900913
i guess you relate to EPSG4326:
"There are a few things that you are mixing up.
Google Earth is in a Geographic coordinate system with the wgs84 datum. (EPSG: 4326)
Google Maps is in a projected coordinate system that is based on the wgs84 datum. (EPSG 3857)
The data in Open Street Map database is stored in a gcs with units decimal degrees & datum of wgs84. (EPSG: 4326)
my problem is that 900913 is actually not listed on https://spatialreference.org/ ->** can be used to generate proj4 reference code like https://spatialreference.org/ref/sr-org/7483/proj4/ for absolute accurate coord.-to-cartesian-converion**

---

thanks again for the project. its really great!! im having problems with spherical geometry in react-fiber though...planning to publish a react-preset, but spherical, is just not working... anyway thanks for support!- leo

[ji-podhead]

since epsg:3857 cuts the map at +-85° latitude, im kinda confused about the projected coordinates, i guess that is why people had problems with extremely distorted poles. right now i use +-19949545.833216466 as boundary, but thats not really relating to 40030/2 (Earth's circumference/2). 19949545.833216466 derived from datumstospherical-boundaries with mapscale=Earth's circumference*10^x

[ji-podhead]

ok i get it now, the epsg guys refused to give it a valid epsg number:
[Unfortunately, however, EPSG were rather dismissive of the system used by Microsoft and Google (more details in a bit) and refused to assign it an official EPSG code. An EPSG statement (as reported by Morten Nielsen ) read:
------>“We have reviewed the coordinate reference system used by Microsoft, Google, etc. and believe that it is technically flawed. We will not devalue the EPSG dataset by including such inappropriate geodesy and cartography.”

[ji-podhead]

allrighty i finaly found the awnser to my question:
" I think the confusion comes from that they actually use two spatial reference systems at the same time:
Geographic Longitude/Latitude coordinatesystem based on the standard WGS84 datum.
Mercator projection using a datum based on WGS84, BUT modified to be spheric.
... If you want to create image overlays, or roll your own tile server on top of the map, you will need to project your images into a spheric mercator projection. The JavaScript APIs are not able to do this for you.
Here’s a bit of facts about the two projections:
The valid range of (1) is: [-180,-85.05112877980659] to [180, 85.05112877980659].
The valid range of (2) is: [-20037508.3427892, -20037508.3427892] to [20037508.3427892, 20037508.3427892]"
those are the boundary values i was looking for!!!!!!!!! i thought that only lats below |85°| are valid, while the tiles are actually streched over the fixed earth circumference, but this is only true for the non-spheric mercator projection(1)

[ji-podhead]

so is it possible to use Equirectangular projection for planes?