Projections, or "Plate Carree considered harmful"

[jbinto]

A little background:

The city supplies ESRI shapefiles in the following formats:

• Bikeways (MTM 3 Degree Zone 10, NAD27)
• Bikeways (WGS84 - Latitude / Longitude)

The former is SRID 2019 (Toronto/S. Ont. specific), the latter SRID 4326 (Plate Carree projection).

When using the SRID 2019 data and using PostGIS st_transform to convert to WGS84/4326, we get "reasonable" results but the misalignment to Google Maps is unacceptable (see #1).

When using the SRID 4326 data directly as a geometry (as opposed to a geography), we have fairly good matching with Google Maps. Some routes appear a little off, but closer examination with the satellite view proves the city's data more accurate than Google's. (n.b. this is an n=1 conclusion, further research needed)

However, the third option we haven't tried yet is storing lat/lng natively in a geography. According to Daniel Azuma on his GeoRails series:

You might be tempted to store latitude and longitude in a geometry type column. That is, to set up your PostGIS column with a geometry type, but use SRID=4326 (which is the EPSG number for WGS 84 latitude and longitude).

Don't do this.

I did this a few times in my naive youth, and it came back to bite me. What you're really doing here is employing a particular projection called Plate Carree, which simply maps latitude and longitude directly to x and y on the plane. Remember, any time you use geometry rather than geography, you are working with a flat coordinate system, and thus a projection. You might think you're working with latitude and longitude, but you're actually not.

Plate Carree is not a particularly useful projection (except that it is trivial to compute). It doesn't preserve distances, angles, directions, areas, or any other cartographically useful properties, and its distortion in polar regions is severe. In almost all cases, you can do much better with a different projection.

He suggests using a Mercator (EPSG:3785) projection that is used by Google Maps.

But here's the problem: My data is fixed. I am not creating any data myself. While I could transform the city's data to whatever projection I want, I currently only have two uses for the data:

• Displaying it on Google Maps (which takes real lat/lng as input)
• Calculating the lengths of the paths (more precise the better)

In hindsight, it seems obvious that KML was intended for Google Earth, a 3D application. That Google Maps accepts KML is surely a result of the synergies between the two, but it was easy to forget that Maps is a 2D application, despite accepting 3D coordinates.

I do not see any benefit to storing my data in EPSG:3785 when that is none of the following: the form my input data is in, the form my output data must be, nor the most efficient/accurate way to perform distance calculations.

This issue will remain open until I can wrap my head around the tradeoffs between these projections.