Geography(4326) is an unbounded, and unprojected, and covers the entire world with ellipsoidal coordinates. I get that the math on this system is done on a spheroid. I also get that with a
geometry the math is done on a Cartesian grid. What I really would like to understand is how SRS 4326 can be subject to both ellipsoidal calculations, and Cartesian calculations without reprojection (like
SELECT ST_Distance( ST_MakePoint(0,0)::geography, ST_MakePoint(1,1)::geography ); st_distance ----------------- 156899.56829134 (1 row) -- same result as ST_MakePoint(x,y)::geography::geometry -- same result as ST_SetSRID( ST_MakePoint(x,y)::geometry, 4326 ) -- same result as ST_SetSRID( ST_MakePoint(x,y), 4326 ) SELECT ST_Distance( ST_MakePoint(0,0)::geometry, ST_MakePoint(1,1)::geometry ); st_distance ----------------- 1.4142135623731 (1 row)
By extension, MySQL does not support nearly the amount of Geographic operations as PostGIS. Worse, it determines the type of calculation (geometric vs geographic) based not the type (as with PostGIS's
geography) but based merely as the SRS ID marker. For any operations that do not support a geodetic reference system, you have to use a Cartesian reference system (which is obviously major suck because MySQL can't reproject). But why if it has these two shortcomings (fewer geodetic calculations), and an inability to reproject can it not do a geometric calculation (Cartesian reference system) with SRS ID 4326? Lastly, is there any SRS ID that is not geodetic that behaves like PostgreSQL
geometry type in SRS ID 4326, so I can use it with MySQL?