The problem is with the CRS of the base layer of my project, Web-Mercator EPSG:3857. This CRS has meter as unit. This means that the point coordinates of my feature are meters, for the x value the distance from the Greenwich Meridian measured along the equator, and for the y value the distance along the local meridian measured from the equator.

This implies that these coordinates should not be used for distance measurements, unless you are in places like Equador, Cameroon or Borneo. In the USA, or Europe, you will find, that the y coordinate diff is precise, but the x coordinate diff is wildly too long. It should at least be multiplied by the cosine of the local latitude to have any reasonable validity.

This is pretty exactly what the "ellipsoid" distance calculates. IMHO, the QGS Python documentation should point this out more clearly in the discussions about the distance calculator QgsDistanceArea. In fact, the "ellipsoid" calculation transforms the input points to lon,lat coordinates, calculates the great-circle curve between them, and measures that curve in terms of the ellipsoid, in display units (meters in this case).

I tried to clarify this in more detail to explain the base problem, which is why the "cartesian" distance of my example is a full mile longer than the "ellipsoid" distance. I realise that this answer is a paraphrase of user30184's comment above.

The problem is with the CRS of the base layer of my project, Web-Mercator EPSG:3857. This CRS has meter as unit. This means that the point coordinates of my feature are meters, for the x value the distance from the Greenwich Meridian measured along the equator, and for the y value the distance along the local meridian measured from the equator.

This implies that these coordinates should not be used for distance measurements, unless you are in places like Equador, Cameroon or Borneo. In the USA, or Europe, you will find, that the y coordinate diff is precise, but the x coordinate diff is wildly too long. It should at least be multiplied by the cosine of the local latitude to have any reasonable validity.

This is pretty exactly what the "ellipsoid" distance calculates. IMHO, the QGS Python documentation should point this out more clearly in the discussions about the distance calculator QgsDistanceArea. In fact, the "ellipsoid" calculation transforms the input points to lon,lat coordinates, calculates the great-circle curve between them, and measures that curve in terms of the ellipsoid, in display units (meters in this case).

I tried to clarify this in more detail to explain the base problem, which is why the "cartesian" distance of my example is a full mile longer than the "ellipsoid" distance. I realise that this answer is a paraphrase of user30184's comment above.

The data of my experiment: Location: Cowansburg, PA 11.5 miles WSW of Greensburg, PA, USA Railroad line: Cowansburg - Greensburg, Pennsylvania Railroad

Feature coordinates in EPSG:3857

  #        x                y
  0        -8878226.1285    4903036.6079
  1        -8878158.6597    4903096.1392
  ...      ...              ...

Coordinate differences between points 1 and 0

           67.4688          59.5313

Cartesian distance EPSG:3857:  89.978 meters

Feature coordinates in WGS84 as per pyproj.Proj('EPSG:3857') inverse
rounded for 1 cm projected precision

  #        x             y
  0        -79.754462    40.254787
  1        -79.753856    40.255195
  ...      ...                   ...

Ellipsoid distance WGS84: 68.648 meters

The ellipsoid distance was calculated in QGIS by a Python instance of QgsDistanceArea, properly configured with Project ellipsoid and, very important, with the CRS of the "rails" line layer, and the transform context of the Project. I spent a full day trying to understand the ridiculous values the calculator gave me, when I did not know that the project transformContext was essential. Another point for the Python Documentation project. I used the measureLine method on two QgsPointXY instances with the above coordinates.

The problem is with the CRS of the base layer of my project, Web-Mercator EPSG:3857. This CRS has meter as unit. This means that the point coordinates of my feature are meters, for the x value the distance from the Greenwich Meridian measured along the equator, and for the y value the distance along the local meridian measured from the equator.

This implies that these coordinates should not be used for distance measurements, unless you are in places like Equador, Cameroon or Borneo. In the USA, or Europe, you will find, that the y coordinate diff is precise, but the x coordinate diff is wildly too long. It should at least be multiplied by the cosine of the local latitude to have any reasonable validity.

This is pretty exactly what the "ellipsoid" distance calculates. IMHO, the QGS Python documentation should point this out more clearly in the discussions about the distance calculator QgsDistanceArea. In fact, the "ellipsoid" calculation transforms the input points to lat,lon coordinates, calculates the great-circle curve between them, and measures that curve in terms of the ellipsoid, in display units (meters in this case).

The problem is with the CRS of the base layer of my project, Web-Mercator EPSG:3857. This CRS has meter as unit. This means that the point coordinates of my feature are meters, for the x value the distance from the Greenwich Meridian measured along the equator, and for the y value the distance along the local meridian measured from the equator.

This implies that these coordinates should not be used for distance measurements, unless you are in places like Equador, Cameroon or Borneo. In the USA, or Europe, you will find, that the y coordinate diff is precise, but the x coordinate diff is wildly too long. It should at least be multiplied by the cosine of the local latitude to have any reasonable validity.

This is pretty exactly what the "ellipsoid" distance calculates. IMHO, the QGS Python documentation should point this out more clearly in the discussions about the distance calculator QgsDistanceArea. In fact, the "ellipsoid" calculation transforms the input points to lon,lat coordinates, calculates the great-circle curve between them, and measures that curve in terms of the ellipsoid, in display units (meters in this case).

I tried to clarify this in more detail to explain the base problem, which is why the "cartesian" distance of my example is a full mile longer than the "ellipsoid" distance. I realise that this answer is a paraphrase of user30184's comment above.