When I needed formulas for calculating Great circle Bearings and Distances, I first searched the Internet. Just to find that there is a lot of confusion out there about the difference between Great Circle bearings and Rhumb Line bearings. Finally found correct formulas in a book on my own bookshelf! The largest challenge was to get the bearings into the correct quadrants.
And finally, the Atan2 function was posted by GWS (Thanks Graham!). It is slightly rearranged before using it here.
PS almost forgot to say that the code includes calculations for b3earing and distance f4rom my home to places around the world.
Very interesting. Have you ever noticed that most sites where you can get Lat and Long seem to differ as to where a city is located. Looked up Auckland, NZ and your value is different than what I could find from a couple of different sites. Was wondering how much difference a few points off would make in the distance.
At my work we have a file with info for all the US cities and even it differs from other sites. I wonder how they determine what they think is the correct value.
I've noticed the same thing. And I reckon that where a geo point is set, is more or less up to the people producing maps. The positions I have used in the example, are all the registered positionsm of the Arinc transmitter sites, used for data communications with international flights. And these transmitters are most often located at remote places, far from city centers. But they always use the same name as the nearest city.
When coding the posted example, I set precision to zero, so the rounding errors will in some cases be rather large. But if the positions passed to the distance routine has a greater precision the result will be more accurate.
I have only tested the code with CB, and using ten decimals slowed down the process very much. But for the application I plan to make, I'll only use the code for indicating the course of the decoded flight data, and show it on a map. For this the calculations will be of sufficient accuracy.
But if tanslated to IWB code, the speed should increase noticeably. In fact, that is what I plan to do when I have made all the routines I need, and see that everything works ok.
Interesting. At least I would assume that the positions given for your transmitter sites won't change, should make things a lot more standard.
This morning we made some simulations on the chart machine (Kongsberg) onboard a local trawler. We simulated making a sailing plan for sailing the vessel between here and Tromsoe, along the coast. Then I put the resulting waypoint positions into my own code to see the difference. The legs varied in length from 16 to 128 nautical miles.
The bearings were all exactly the same on both systems, regardless of number of decimals. But the distances varied slightly between the two systems. Then I increased precision with one decimal at the time. From 6 decimals and up, both systems showed exactly the same results.
This was a positive surprise, as I never thought that the CB code was so accurate. Therefore I assume that for more accuracy on longer distances, you have to use more decimals.
In case you want to experiment, I attach the latest Arinc system table. It is transmitted from the mentioned transmitter sites once a year, plus in case any frequency is changed. This one came when they set up a new transmitter site in Muan, South Korea, ten months ago.
That is where I found the positions, before I converted them into degrees with decimals.
In cas you see how to improve the calculation routines, please let me know.
Sounds like you're having fun .. :)
The reason CB is so good at calculations, is that it uses a very simple but ingenious math approach.
All calculations are done to maximum precision, and the results are then rounded to the specified precision.
That's pretty neat :)
Over the years, it's been tested on heavy applications such as seismology, which required 5 dimensional arrays. Hence IonicWind programming systems from CB onwards were developed to be capable of handling arrays of up to 5 dimensions. Clever stuff .. ;D
Hope you are well .. :)
Finally got rid of the cancer. But still need some time to recover, so exercise like a madman to be ready for long walks in the mountains again. In the meantime I'm having fun coding. This is something I have been thinking of for a long time, and when I found both the Atan2 and the Distance routines in my CB snippet collection I had no choice. I had not noted where I have copied the Distance code from. Suspect it once was coded by a certain gentleman from Staffordshire...
And you are absolutely right about Creative Basic, the only thing I really miss is being able to use DATA statements. But that is no big deal.
Anyway, it is great to be back in business.
All the best!
That's good news you're recovering.
Ah yes .. the DATA statements. Never did like them myself - too complicated with BEGIN, END, GET, RESTORE etc. I always preferred to use arrays to store and access data.
All the best, :)
Since I don't use Creative Basic, I am asking, can it use Assembly routines?
This was on the forum, created by Ficko. Works quickly and does not use Data statements.
FOR l = 0 TO 9999
kw[0,l] = ""
kwm = -1
sp = 1
l = INSTR(*<STRING>&MyData,"\n",sp)
WHILE l > 0
s = MID$(*<STRING>&MyData,sp,l-1)
IF s <> "ZZZEND"
kw[0,kwm] = s
sp = l + 2
l = INSTR(*<STRING>&MyData,"\n",sp)
KeyWords.txt is 1 line per record, has CR/LF, which is why I need to do 2 chars to get to the next record.
Inline assembly was introduced in Emergence Basic. It uses the _asm keyword and ends the assembly block with the _endasm keyword. Any text between the two statements will be ignored by the Emergence compiler and is copied verbatim to the resultant compiler .a output file at whatever point the _asm statement appears.
Since Creative Basic is not a compiler, this isn't possible.
Best wishes, :)
When using the routines above to plot the Great Cirlce routes on a world map, I soon discovered that the error margins when using ordinary trigonometry formulas for calulating distances became increasingly higher as distance increased. These errors became more obvious when comparing the calulated distances with Google Maps. Therefore i have changed the code to use the Haversine formula for distance calulations. Was unable to find the formulas in my own collection so had to search the web. The sesults were houndreds of links to the Haversine formula, most of them were different.
Also found a link to a site with coding examles for a lot of programming languages: https://rosettacode.org/wiki/Haversine_formula
The new code is posted below. If you download and unpack it, you will notice that there are two different subs calculating the distance. One of them is "remmed out". Both routines produce the same resuilt, but I posted them both just to demonstrate that things can be done in very different ways.
The distance calulatons still differ from Google, but now the results are satisfactory for my purpose. And as always, if you spot errors or see how the code can be improved, please let me know.