3

3/28/2022 Measure line tool: I have attached two pix showing the Measure-Line tool used to measure my line (representing a rail corridor). 1. Measure_Line_Cartesian.jpg shows the Cartesian measure of 109 km (which is not accurate). 2. Measure_Line_Ellipsoidal.jpg shows the Ellipsoidal measure of 79 km (which is accurate).

Locate points along lines plugin: I’ve attached two pix showing my use of the ‘Locate points along lines’ plugin: 1. LocatePointsAlongLines_setup.jpg shows my setup dialog used to create the end-points. 2. LocatePointsAlongLines_AttributeTable.jpg  shows the end-point ‘distance’ attribute value of 109 km.

The problem:
I need the 79 km value for the end-point ‘distance’ attribute value because that is the accurate length of the line. I don’t know how to configure the plugin to calculate the correct ‘distance’ attribute value. I think, just like the ‘Measure_Line’ tool, there needs to be some way to configure this plugin distance calculation (based on either Cartesian or Ellipsoidal). Projected coordinates are Web Mercator (EPSG:3857).

0

2 Answers 2

2

The basics

Neither the plugin's documentation nor the QGIS native tool Points along geomtry (which I would recomend) does mention any possibility to change between cartesian and ellipsoidal distances. Why that is should become clear in what follows. Ellipsoidal distances follow great circles:

The minor arc of a great circle between two points is the shortest surface-path between them. In this sense, the minor arc is analogous to “straight lines” in Euclidean geometry.

From Wikipedia: Great Circle

See also: Wikipedia: Great Circle Distance, Great Cirlce Navigation and Geodesic.

So for what you want to do, some basic knowledge about projections is necessary.

The solution

To achieve your goal, create a custom oblique azimuthal equidistant projection. This projection returns "true" (ellipsoidal) distances from one point (the center of the projection) to all other points on the map. This is easy to do using Projectionwizard.

For background about this projection see ESRI: Azimuthal equidistant and Wikipedia: Azimuthal equidistant projection

Step by step workflow

  1. Get the lat/lon coordinates of the point from where you want to start measurement (the line's start point).

  2. Go to https://projectionwizard.org, click equidistant projection, below enter roughly the coordinates of your start point and when done, click WKT and then copy the WKT definition (see screenshot and projection defintion in WKT format at the bottom).

  3. In QGIS, go to Menu Settings > Custom Projections..., click the green + to add a custom projection, enter a name and paste the WKT definition from above. Change the values for Central_Meridian and Latitude_Of_Origin to the exact lon/lat values you want (see step 1). Cf. screenshot at the bottom.

  4. Reproject your line (e.g. using save/export) and use the custom CRS created before.

  5. Use the resulting line with Menu Processing > Toolbar > Points along geometry and set the distance you want.

Explanations

The result looks like this: black = initial line, blue = points along the line: exactly 200 km away from each other. You will object "but they do not lie on the line" - well, this is not true as I will explain below:

enter image description here

The map canvas above is in project CRS EPSG:3857, thus in a (Mercator) projection that heavily distorts distances the further you get from the equator: north of Greenland (as in my screenshot), distortion is extreme. So the black line you see connects start- and end-point of the line in this distorted projection.

The "real" line - the shortest connection between start- and end-point on Earth's surface - follows the shape of the red line (you get this red line using Menu processing > Toolbar > Densify by interval).

You see that if you change the project CRS to the custom projection from step 2/3 as in the following image. The black line now follows exactly the blue points, where the red line here represents a line drawn in EPSG:3857. The point at the bottom left (red arrow) is the center of the projection: all measurements starting with this point return correct (ellipsoidal) values:

enter image description here

That this is indeed the "true" shortest path connecting start- and end-point on Earth's surface can be seen on a globe, e.g. if you export the line and open it in Google Earth. As you can see, the direct path does not intersect with northern Greenland:

enter image description here

Step 2: projectionwizard enter image description here

Step 3: Creating custom projection - paste WKT definition enter image description here

This is how the WKT definition looks like for the point I used (76° N 82° W)

PROJCS["ProjWiz_Custom_Azimuthal_Equidistant",
 GEOGCS["GCS_WGS_1984",
  DATUM["D_WGS_1984",
   SPHEROID["WGS_1984",6378137.0,298.257223563]],
  PRIMEM["Greenwich",0.0],
  UNIT["Degree",0.0174532925199433]],
 PROJECTION["Azimuthal_Equidistant"],
 PARAMETER["False_Easting",0.0],
 PARAMETER["False_Northing",0.0],
 PARAMETER["Central_Meridian",-76],
 PARAMETER["Latitude_Of_Origin",82],
 UNIT["Meter",1.0]]
5
  • Hi @Babel. Thank you so much for your thorough, eloquent, quick, and thoughtful response. I plan to work through your solution however, since I am a newbie, it will take me a while.
    – Doug
    Commented Mar 28, 2022 at 21:03
  • Hi @Babel. First, I’d like to learn the native ‘Points along geometry’ tool because you recommended it. The tool does not need to be configurable (between Cartesian and Ellipsoidal) if it measures accurately (using a great circle with the WGS 84 Ellipsoid). I was hoping to avoid working with projections thinking that, at this point in my project, I am not mapping. I’m just trying to get an accurate distance for the endpoint. This value will be used for the LRS (Linear Reference System) work that follows.
    – Doug
    Commented Mar 28, 2022 at 21:04
  • If you're dealing with "real" (ellipsoidal) distances, this means great circle lines - so I fear you can't avoid thinking about projections. Be aware that drawing a line in any but equidistant projections does not represent the real shortest line (=ellipsoidal distance). So measuring ellipsoidal distance makes only sense if you have a line that respects this.
    – Babel
    Commented Mar 28, 2022 at 21:24
  • 1
    @Babel, this is an excellent, detailed answer. Given the OP's interest in distances along a linestring (not straight), your advice to create a custom azimuthal equidistant projection (centred at a line endpoint?) may be more effort than required. The OP doesn't say what his projection is (not helpful) but a simple answer would be, as you suggested, to use the "points along geometry" tool but project the data reasonably for distance estimation first (UTM, a reasonable conic - almost anything other than the default web mercator - just guessing...).
    – hgb
    Commented Mar 30, 2022 at 15:44
  • Thanks @hgb for your comment. Feel free to add an answer using UTM projection - might be indeed easier.
    – Babel
    Commented Mar 30, 2022 at 16:11
2

Method 1: use Locate Points Along Lines with appropriate projection

The "Locate points along lines" (LPAL) plugin calculates distances along the line using the coordinate system in which the geometry is stored. The "points along geometry" tool suggested by @Babel probably works the same, from the little testing I did, but it doesn't force a point at the end node of the line so won't give you the exact distance you want. Sorry, you can't avoid it - you do need to think about projections when measuring the distance.

Below I run LPAL plugin twice on a line that is located mid-latitude (about 43°N), first using Web Mercator (EPSG:3857) coordinates and then using coordinates for a UTM zone appropriate to the area (EPSG:32617). Web Mercator is known to elongate East-West distances as you use it with features away from the Equator. As you can see in the attribute table when the plugin is run on the geometry stored using Web Mercator (3857), the last point, added at the endpoint, is calculated as 835.75 metres from the start of the line.

enter image description here

Running the same procedure on the same line reprojected into WGS84 UTM Zone 17N (32617) results in a line length of 603.79 metres, as shown by the distance for the last point. The distance measured in UTM will be much closer to the truth so measuring a mid-latitude geometry when projected in Web Mercator is adding 38%!! Similar to the results you are seeing.

enter image description here

Your projected length calculation, using EPSG:3857, is overestimating the line length in a predictable way. That projection is not useful for measuring distances.

Which projection will work best depends on where your line is. Figuring out which UTM zone the line is in and projecting the line into that coordinate system will yield better results. Some conic projections would also be good. There are many possible projections that will yield better results for you but that's beyond the scope of this question.

Method 2: Pre-calculate line lengths and carry them along in Locate Points Along Lines as attributes:

This method does not require the selection of a projection appropriate for the measurement of distances. This uses the project measurement settings as described here: Different length measures in QGIS vs. ArcMap.

Steps:

1: make sure measurements in project are set to use ellipsoid distances in measurement units you want. Here, I show units of metres.

2: Add calculated line lengths to all your lines. Use the field calculator to create a column containing the calculated lengths ($length) for your line layer.

3: Use Locate Points Along Lines, selecting both keep attributes (to bring the ellipsoid length just calculated along) and add endpoints (to ensure that a point is added at both line endpoints to give exactly the locations you want). In the image below, see the checkmarks for those options. Also, I have set the interval high enough for this set of lines so that only the endpoints are generated - adjust if you want some points along the line but, as I understand the question, those are unnecessary.

enter image description here

The result of this is a point layer with points at the end of each line and attributes from the line for which the endpoints were generated, including the ellipsoid line lengths calculated above. Each point has attributes including the identifier of the line it is associated with (id), the ellipsoid length (length) transferred by keeping attributes. The other fields, org_fid and distance (calculated in degrees because the layer is stored using WGS84 lon/lat coordinates), were calculated by LPAL.

Note: if you need to distinguish the start and end points associated with each line, you can do this by examining the distances. Calculate a new column on the points layer, selecting the distance field if it is 0 and the length field when distance is not 0.

enter image description here

12
  • Temporarily waylaid. I use EPSG:4326 (for unprojected), and EPSG:3857 (for projected).
    – Doug
    Commented Mar 31, 2022 at 13:43
  • @Doug Thanks for the update. That was my guess. My discussion will apply to what you are doing. But also see the update I just added - if you only want the overall length of the line and the "locate points along lines" plugin was just how you were trying to get that, field calculator is probably what you actually want to use.
    – hgb
    Commented Mar 31, 2022 at 13:55
  • The new, calculated length attribute value on my line layer (from the $length expression) gives an accurate length. Thank you! That was very helpful. What I need (for the LRS plugin | Calibration procedure) however is two input layers: 1. My original line layer (representing my single route) which I have. 2. A points layer containing the two endpoints (of the route). The attribute table (with 2 rows) would have an attribute for the route-id and one for the lengths. The startPoint would have a length of zero. The endPoint would have the length of my line (my route).
    – Doug
    Commented Apr 1, 2022 at 20:52
  • 'QChainage' and 'Locate points along lines' both create this points layer. However, they are both problematic for different reasons. My unprojected line layer (epsg: 4326) gives me length units in 'degrees' (that appear to be accurate) but I can't convert degrees to meters or miles. My projected line layer (epsg: 3857) is gives me length units in meters but they are in the Cartesian CS which is not accurate.
    – Doug
    Commented Apr 1, 2022 at 20:53
  • 1
    @Doug, I have added a 2nd method that explains this approach. Pre-calculate the ellipsoidal length on the line layer and then keep those attributes when generating the endpoints.
    – hgb
    Commented Apr 2, 2022 at 19:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.