QGIS : EPSG4326 : arc of circle with X radius centred in Z (aviation)

Question

I am trying to make a polygon from the aviation LPPO FIR (Santa Maria Oceanic Flight Information Region), that some portion is described as "arc of circle with 100NM radius centred at PST NDB (anti clock-wise)".

DATA (DDMMSS):

• PST NDB : 330407N 0162130W
• Start point of arc : 341504N 0174605W
• Ending point of arc : 3215N 01438W

In QGIS 3.24.3-Tisler:

• Fresh project in EPSG4326
• Plotting DATA coordinates in a point layer (EPSG4326)
• Making a circle with vector_geometry/buffer or python_script - Layer (EPSG4326)

Can obtain a visually close "perfect circle" (adding decorations/grid seems a perfect circle) but with a radius of ~99.455NM in Y axis, and only ~85.865NM in the X axis with measure_line/elipsoidal (in cartesian Y:~99.813NM X:~102.355NM)

the drawn circles also do not reach the points of start/end of arc of circle.

adding a layer with the actual boundary for comparison, the draw circle has the right dimension on N/S but wrong in E/W - the actual shape should be more close to a horizontal ellipse.

Work around Using online Vicenty calculator, determine 2 point at a distance of 100NM from PST NDB and with 180º and 270º (respectively south and west) and then using "add ellipse from center and 2 points" with the PST NDB and this 2 new points to draw an ellipse that looks closer to the layer with the actual boundary.

Question What is the issue here, knowing that maintaining the same CRS /EPSG 4326.

Is there any path to do it properly, and without the need to create the 2 additional points for reference? or using the alternative method below.

Additional Information Plotting a circle using the https://www.fcc.gov/sites/default/files/circle-plot.html and importing the KML to QGIS, the 100NM radius "circle" measure ~99.767NM in X and ~100.225NM in Y and superimposes all the expected coordinates looking pretty close to the expected.

Answer 1

Your problem stems from the use of EPSG:4326 when generating your arc. While 4326 is fine for locating point data, it should not be used with anything that involves distance or area (including line or polygon data). That's because 4326 uses lat/lon values instead of meters or feet, and the distance (expressed as degrees) between any two lines of longitude shrinks as you move from the equator to the poles. At the poles the distance becomes zero. You can see this by observing a globe. Meanwhile, the distance between any two lines of latitude stays relatively constant (it would be constant if the earth was a perfect sphere, but it bulges a little here and there, causing small variations in the distance between parallels).

You can see this in your results: The Y-axis (latitude) is pretty close to 100nm, but the X-axis (longitude) is way off.

The solution is to convert the point data from 4326 to a projection that uses meters or feet. Here's the approach I took:

1. Add the three data points, using their lat/lon values, as EPSG:4326
2. Export the points to a new layer that uses a projected CRS in meters or feet. I chose EPGS:32628 (UTM 28N, meters)
3. Remove the EPSG:4326 points and load the new EPSG:32628 points into QGIS. Inform QGIS that you're now operating in EPSG:32628 with Project > Properties > CRS and search for 32628. Make that the project default and click ok.
4. Buffer the center point (the Santa Maria NDB) by 185,200 meters (which is equal to 100 nm). Note that this buffer polygon will be in EPSG:32628, which is what we want.
5. Convert the buffer polygon to a line, which will also be in EPSG:32628.
6. Split the line using the two outer points with the Toolbox > Processing > SAGA > Features-lines > Split lines at points tool. Set the Epsilon value to 300 (Epsilon acts like a search distance (in meters) between the line and each point. This is required because the two points are not exactly coincident with the line; they are within +/- 289 meters).
7. Voila! A split line. Select the southerly segment, which coincides with the start/end, anti-clockwise requirement.

Answer 2

Principal considerations

No projection can preserve distances but only for a small part of the map (see here for more details) - be it along a line or only for distances from one (or two, using Two-point equidistant projection) points to all other points on the map.

Just imagine: if all distances could be preserved, in conclusion that would automatically mean that also all areas and all angles would be preserved and you would have in fact a non-distorted map. As this is impossible, it also means that, using any kind of projection, most distances except for some special cases will not pe preserved.

Solution

So creating a custom projection that preserves distances from you center point of the radius is a way to go. Proceed as follows:

1. Create a custom equidistant projection (custom CRS), centered on PST NDB. See here how to do that (and below for the CRS definition): https://gis.stackexchange.com/a/427314/88814

2. Create a point layer in the layer CRS created above and make a point at the center of the circle (PST NDB) - or simply reproject (export > use CRS defined above) your already existing point.

3. Set project CRS in EPSG:4326, create a polygon based on the point with Geoemtry Generator or Geometry by expression (see here for details), based on the point layer, with this expression:

   buffer ($geometry, 185200) -- change the distance of the buffer if necessary
   

   To get only a line (circle instead of polygon), use:

   boundary (buffer ($geometry, 185200))
   

CRS definition: Azimuthal Equidistant projection, centered at 33.0407 N 16.2130 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",-16.2130],
 PARAMETER["Latitude_Of_Origin",33.0407],
 UNIT["Meter",1.0]]

Map is projected in EPSG:4326, that's why equal distant buffer appears not as a circle, but as an ellipse: