Lazarus

Free Pascal => Beginners => Topic started by: JLWest on July 02, 2020, 08:42:47 am

Title: Problems with time and Distance Help Please
Post by: JLWest on July 02, 2020, 08:42:47 am
I have been working on this for 4 days. I couldn't get it to work in the program so I broke out the problem and put it this demo. Compile and go no file loading all self contained  3 or 5 short procedures.

 I need to know the local time at EDAM and RiBB.

I think if the figures are right the GMT time at the
aircraft is 23:53:52, RJBB is 16:48:33 and there is 2 hrs 14 min
and 51 sec left to EHAM the destination.

I also need to know if the figures are reasonably correct. Because of the Haversine calcs and other factors it can never be really correct.

I have included a form screen shot, the program and the code.

The data comes from a provider who has ADS-B access. I make an API call and get an XML doc of a 1,000 or so flights. Some flight are in the air, landed, started or unkown,

I also get a departure and arrival airports Lat/Lon of of the aircraft in route and a Unix EPOCH GMT time at the Lat and Lon position.
plus the call sign carrier, aircraft.

    Thanks
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 02, 2020, 12:44:32 pm
Hi!

After a short reading your code I detected one error.

This line is wrong :

Code: Pascal  [Select][+][-]
  1. D := arcsin(sqrt(dx**2 + dy**2 + dz**2) / 2) * diameter;
  2.  
The division  by 2 should NOT  be inside the arcsin  but

Code: Pascal  [Select][+][-]
  1. D := arcsin(sqrt(dx**2 + dy**2 + dz**2) ) * diameter/2;

And please: Don't compute miles. Since 1975 the rule for scientific work is to use metrics.
The last time the NASA did  not respect that rule the "Mars Climate Orbiter" missed  the Mars. And 200 Million $ vanished in the universe.

Winni

Title: Re: Problems with time and Distance Help Please
Post by: Thaddy on July 02, 2020, 12:55:01 pm
Further more "mile" is not well defined.
https://en.wikipedia.org/wiki/Mile
whereas metrics are....
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 02, 2020, 01:08:31 pm
Hi!

I will take the mile of my home : the landmile of Schleswig-Holstein (northern germany). It was about 10.5 kilometer. Nobody knew that exact. But valid until 1871!

Winni
Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 02, 2020, 08:51:25 pm

I changed the line as you suggested and get a SIGPFE error on the call to the  HaversineDist function.

As for going to the metrics system it would mean a rewrite. Not in the Demo but in the program. The Haversine formula gives miles. I'd have to find one that gives kilometers

Because I have GMT time for RJBB and EHAM at this point I need to convert those times to Local for each location.

So I would have to convert the Unix EPOCH Int64 to TDateTime using UnixToDateTime. And then use UniversalTimeToLocal to get the local times.

function UnixToDateTime(const AValue: Int64;aReturnUTC: Boolean = True ):TDateTime;

{function UniversalTimeToLocal(UT: TDateTime; TZOffset: Integer):TDateTime;}

 



Hi!

After a short reading your code I detected one error.

This line is wrong :

Code: Pascal  [Select][+][-]
  1. D := arcsin(sqrt(dx**2 + dy**2 + dz**2) / 2) * diameter;
  2.  
The division  by 2 should NOT  be inside the arcsin  but

Code: Pascal  [Select][+][-]
  1. D := arcsin(sqrt(dx**2 + dy**2 + dz**2) ) * diameter/2;

And please: Don't compute miles. Since 1975 the rule for scientific work is to use metrics.
The last time the NASA did  not respect that rule the "Mars Climate Orbiter" missed  the Mars. And 200 Million $ vanished in the universe.

Winni
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 02, 2020, 10:18:19 pm
Hi!

The division by two inside the arcsin is definitly wrong.

So for better results use:

Code: Pascal  [Select][+][-]
  1. const Deg2Rad= pi/180;
  2.  
  3. Function EarthDistance (const long1, lat1, long2 , lat2 : single): single; inline;   // km
  4.  Const R = 6371.000; // km
  5. var Fi1, Fi2, DeltaFi, DeltaLambda, a, SinDeltaFi2, SinDeltaLambda2  : single;
  6.  
  7. begin
  8. Fi1 := Lat1 * Deg2Rad;
  9. Fi2 := Lat2 * Deg2Rad;
  10. DeltaFi := Fi2 - Fi1;
  11. DeltaLambda := (Long2 - long1) * Deg2Rad;
  12.  
  13. SinDeltaFi2 := sin (DeltaFi*0.5);
  14. SinDeltaLambda2 := Sin (DeltaLambda*0.5);
  15. a :=  sqr (SinDeltaFi2) +
  16.       cos (Fi1)* cos(Fi2) *
  17.       sqr (SinDeltaLambda2);
  18. result := 2 * arctan2(sqrt(a), sqrt (1-a));
  19. result := R * result;
  20. end;
  21.  


And concerning the time:

Compute everything in UTC (GMT is dead).
And if your results are fine, you can start to try to convert it in local time.

But that is a lousy thing. Pilots don't do that.

When does the daylight saving time end in Arizona?
Has Turkey now abolished day light saving - as they anounced?
And how many Gulf wars it has taken to abolish the half -hour-time-zone in Irak?

The circumstances are permanently changing. You are heavily involved in political unlogical stuff. Not an easy job .

Winni


Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 02, 2020, 11:54:00 pm
Thanks I'll try it.

And concerning the time:

"Compute everything in UTC (GMT is dead)."

Yea, I know. GMT is a timezone, The website were I do the API call list the time that comes back as GMT. That's why I show the Heathrow info bottom left.

"And if your results are fine, you can start to try to convert it in local time."
"But that is a lousy thing. Pilots don't do that."

It's not really for pilots per say. The final record the program will produce looks like:

OPER  Dep      Arr      AC      DTime   Callsign    AC-ID      Day  ATime
AAL   , KLAX  , KJFK , B778 , 0810  ,  AA2134 , N7548AA   4    1206 

This record is data for a program which generates flights in a Flight simulator. Some of the planes will be parked at a gate, some taxing and some en-route depending on the values in the record.

The above record looks like the info displayed at the airport showing flight information, except they don't have the day value.

Thanks
Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 03, 2020, 12:03:30 am
@winni

  Function EarthDistance (const long1, lat1, long2 , lat2 : single): single; inline;   // km

I don't know how to call the function. I understand the lat1 and lat2 but not the long1, and long2.

Title: Re: Problems with time and Distance Help Please
Post by: winni on July 03, 2020, 12:09:31 am
Hi!

Again (and again and ...) : GMT is dead.
It was replaced in 1972 by UTC .

The only country that talks about GMT is GB.
They also think that the brexit will enrich them .....

About your flight data from Los Angeles to New York:

Between DTime and ATime is a difference of ~ 4 hours.
Is that the real flight time or must we add 3 hours time zone difference?

Europe and China are easier with such things:
Everything in one zone.

Winni
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 03, 2020, 12:20:24 am
@winni

  Function EarthDistance (const long1, lat1, long2 , lat2 : single): single; inline;   // km

I don't know how to call the function. I understand the lat1 and lat2 but not the long1, and long2.

Latitude and Longitude define every point on this earth.
Do you need further information?

And again and again and ... : GMT is dead.
It was replaced 1972  by UTC.

Winni



Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 03, 2020, 12:38:15 am
"Between DTime and ATime is a difference of ~ 4 hours.
Is that the real flight time or must we add 3 hours time zone difference?"

OPER  Dep      Arr      AC      DTime   Callsign    AC-ID      Day  ATime
AAL   , KLAX  , KJFK , B778 , 0810  ,  AA2134 , N7548AA   4    1506

Yea, it's local time so it would be NY local time.

So those are longitudes, yea makes sense now.  I just thought whenever you expressed latitude and longitude latitude always comes first. Now that is an English Convention.

Thanks


Title: Re: Problems with time and Distance Help Please
Post by: winni on July 03, 2020, 01:06:17 am
Hi!

So if lift off is 8:10 in Los Angeleses and touchdown is 12:06 in New York we got ~ 4 hours plus 3 hours timezone Shift. Are 7 hours realistic for a flight west to east in US? I don't know - I am European .

If you have to deal with local times, then these are horrible data. Look if you get some with UTC.

If not: There is a TimeZone package for Lazarus in the Online Package Manager.

I don't no nothing about it, but you can give a try.

But it would be better to get flight data with UTC.

Winni


PS.: Lat/Long or Long/Lat - everything a point of view.
In school we learned that zero  for Y is at bottom.  Now it is a the top ....

Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 03, 2020, 02:57:14 am
The only time I have to work with is the Unix EPOCH 1592610832 at 63.62 Lat / 38.28 Lon.

The provider says the time is an Uniz/EPOCH time and is GMT, however it's really UTC.
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 03, 2020, 11:57:35 pm
Hi!

So I assume that  EPOCH 1592610832 at 63.62 Lat / 38.28 Lon is the temorary time and position of the Airplane. Because this is Russia -  100 km west of Archangelsk.

So why is an Airplane way from LA to NY in Russia?

I don't understand your data.

Winni
Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 04, 2020, 12:19:18 am
@Winni

Sorry for the late reply.

RJBB is Sennan District, Osaka Prefecture, Japan flying to EHAM Badhoevedorp, Noord-Holland, Netherlands. The route would be over Russia.

But there is something wrong with my  math, logic or method I think.

if I calculate the local time for RJBB and EHAM I come up with:

 RJBB Departure Local time:  6/19/2020    16:48  +9(TZ)
EHAM Arrival Local time:       6/20/2020    2207   + 2(TZ)   Net of +7

I don't think those times add up to 9hr 22min. More like 20 some hours.


The flight should take about 9 hr and 22 min.

Trying to find where but can't come up with error.

 


Title: Re: Problems with time and Distance Help Please
Post by: winni on July 04, 2020, 12:39:59 am
Hi!

EHAM airport is Amsterdam Schiphol (Netherlands), number 3 in Europe.

Where do you get the 9:22 hours flight time  from?
Is that in your data?

Winni
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 04, 2020, 12:48:04 am
Hi!

Again: Where are the 9:22 hours flight time from??

A lot of travel agencies in the net tell:

Japan - Europe nonstop takes ~ 12 hours.

So 22 h  minus 16:48 is 5 hours plus a little.
Plus 7 hours time zone shift.
There you are with 12 hours.

Winni
Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 04, 2020, 12:57:21 am
2 Winni

No I don't have in data it's calculated. the distance is 5699 miles. (Trying to go to the metric system but it's a lot of changes).
The cruse of the airplane is 609 miles per hour or 10.15 miles a min.

 so 5699 miles div by 10.15 * 60  = 33,688 secords.

33688 / 60 / 60 = 9.357 which is 9 hours and 21 min

 
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 04, 2020, 01:10:40 am
Hi!

Plus:
Lift off
Touch down
Climb up to 3x.000  feet (or more)
Get down from that height

Seems that takes around 2:30  hours.

Winni

Title: Re: Problems with time and Distance Help Please
Post by: winni on July 04, 2020, 01:19:22 am
Hi!

Daily: KLM 0868
Dep Osaka : 0:30
Arr. Amsterdam: 5:30

Flight time: 12:00 hours.

For tomorrow:

www.klm.de/flight-status/flight-list?date=20200706&originAirportCode=KIX&destinationAirportCode=AMS (http://www.klm.de/flight-status/flight-list?date=20200706&originAirportCode=KIX&destinationAirportCode=AMS)

Winni
Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 04, 2020, 01:25:32 am
The standard they use is 10 min to taxi out, add 7 min. for the SID (Standard Instrument Departure) and 4 min for climb to altitude. The climb to altitude is mostly on route.

Now for approach and landing airliners fly a STAR (Standard Terminal Arrival)

It's to complicated to reasonabily assign time for a star so they add 10 or 15 min.

so that's 31 to 36 min.

I haven't added anything yet. wanted to wait until the figures balanced.

 
Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 04, 2020, 01:29:03 am

It look like my 9 hrs and 22 min is off but the departure from RJBB 1648 and arrival at EDAM of 2207 may be about right.

But how can I prove it in math?
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 04, 2020, 01:29:36 am

The cruse of the airplane is 609 miles per hour or 10.15 miles a min.


That is too much for the most modells in use.

600 mph results in 1000 km/h in 0.9 Mach.
The 747 has a maximum of 0.85 Mach except the very latest machines.

So your  calculation is too optimistic.

Winni
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 04, 2020, 01:32:51 am
Hi!

In math we did it already:

    Arrival Time
  - Departure Time
  + Time Zone Difference

If it is  below zero add 24 hours

Winni
Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 04, 2020, 01:37:11 am
You might be right on the AC cruise. Rechecking now but a B77W cruse is 563 mil per hour or MACH .84.
Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 04, 2020, 02:17:07 am
Yea, that's the problem.

The AC is a Boeing 787-9 with a cruise speed of 567 MPH.

So 567 / 60 =  9.45 MP min.

 5699 / 7.45 * 60 = 45,879

45879 / 60 / 60 = 12.74 or 12.44 min +/-
Title: Re: Problems with time and Distance Help Please
Post by: TRon on July 04, 2020, 06:05:16 am
So 567 / 60 =  9.45 MP min.

 5699 / 7.45 * 60 = 45,879
yeah, no wonder things are going wrong  ;)

speed    = 567 mp/h
distance = 5699 miles
taxi     = 10 min
sid      =  7 min
alt      =  4 min
star     = 10-15 min

total min waste = 10 + 7 + 4 + 10 = 31 theoretical minutes
total max waste = 10 + 7 + 4 + 15 = 36 theoretical minutes

567 miles/hour div 60 min/hour = 9.45 miles/minute (theoretical)

5699 miles div 9.45 miles/minute = 603.068783069 minutes div 60 minutes/hour = ~10.05 hours (theoretical)

10.05 hours flight time at perfect conditions + 31 minutes of perfect waste (which will never happen at a busy airport such as schiphol) = 10.5678130512 hours = ~ 10 hours and 35 minutes (theoretical)
Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 04, 2020, 07:53:00 am
Have to look at those figures but thank you. Just got the function EarthDistance cut into the main program and ran it for the first time.

It gives me 2346.44922 {KM} {Bad lat as input so I hard coded the lat's and lon's to the function}

Is that anywhere close? NO

So after using the EarthDistance function I get  9240.15918 KM which is 5741.55762 miles. 42 KM longer than my original  5699 miles.  It getting closer, at the close of 5 days.

I have a data input to a function I have to run down and it's 11:00pm local time.

Thank you guys for the help.

Title: Re: Problems with time and Distance Help Please
Post by: TRon on July 04, 2020, 08:15:25 am
It gives me 2346.44922 {KM}

Is that anywhere close?
A mile is about 1.6 KM so if that 2346.44922 {KM} is your distance between Osaka and Amsterdam expressed in KiloMetres then there seems to be something off.

The flight distance between Osaka and Amsterdam should be around 5,742 miles which is about 9,241 km

edit: typo
Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 04, 2020, 08:24:51 am
@TRON
yea, I got the same figure. Just discovered the problem, now I need to fix it but it will have to wait for tomorrow.

Thank you

Title: Re: Problems with time and Distance Help Please
Post by: winni on July 04, 2020, 11:55:14 am

A mile is about 1.6 KM so if that 2346.44922 {KM} is your distance between Osaka and Amsterdam expressed in KiloMetres then there seems to be something off.


@JLWEST

I told you not to work with miles. Now you do the same as the NASA did: Miss your destiniation.
Osaka plus 2346 km west you'll arrive in the endless dark Sibiria.
Not so nice.

Winni
Title: Re: Problems with time and Distance Help Please
Post by: wp on July 04, 2020, 12:10:11 pm
[...] 42 KM longer than my original  5699 miles.  [...]
Over such large distances it should matter that the earth is not a sphere but an ellipsoid. Does you distance calculation take care of that? And how is that officially handled?
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 04, 2020, 12:44:42 pm
 Hi!

The deviation from the mean earth radius is

-14 km at the Poles
+7 km at the Equator

In percent this is -0.2% and +0.1%

How do you officially handle if the beer in the pub is suddenly 0.1% more expensive?

Nobody cares about that.
There are hundreds of factors that are more significant for the flight buisiness.

Winni
Title: Re: Problems with time and Distance Help Please
Post by: wp on July 04, 2020, 05:01:19 pm
JLWest is worried about a distance in the calculation by 41 km. I have no idea what he is doing, maybe incorrect conversion between miles and kilometers. I only wanted to point to the error source due to the elliptical shape of the earth. Since I do not have any idea how many km this would be I used the distance calculation from LazMapViewer (which is based on a spherical shape) and that of https://forum.lazarus.freepascal.org/index.php/topic,46737.msg333796.html#msg333796 (whch is based on an elliptical shape) and calculated the distance between the geo locations mentioned further up in the text:

- spherical surface: 9251 km
- elliptical surface: 9264 km

A difference of 13 km. The same order of magnitude observed by JLWest, but only a third of the value. Therefore his error must be somewhere else.

My question about the "official" handling of distance calculation: i picked another example: a flight from Munich (MUC) to San Francisco (SFO). According to https://www.airmilescalculator.com/distance/muc-to-sfo/ the flight distance is 9461 km. The calculation with the spherical surface yields 9448 km, the elliptical surface 9461 km - exactly the result of the airmilecalculator. Therefore, I'd conclude that flight distances are calculated based on the elliptical shape of out planet.
Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 04, 2020, 05:23:16 pm
@WP That's interesting.

I'm not that concerned about the 41 Km difference. I just need a reasonable approximation of the distance, flight times and local times at the start and finish.

 
Title: Re: Problems with time and Distance Help Please
Post by: wp on July 04, 2020, 05:59:23 pm
I just need a reasonable approximation of the distance [...]
In this case forget my post. The calculation based on the spherical surface does in fact provide a "reasonable" distance value for most practical means. Except, maybe, for a very ambitious frequent flyer who could feel cheated if the airline company would calculate flight miles based on the spherical model.
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 04, 2020, 06:44:25 pm
Hi!

The exact distance is not so import between two airports.

The main order is: save fuel, save fuel, save fuel! That's where the money is.

If you can fetch a good jet stream and fly some extra kilometers -  do it: That save fuel.
If you let the passengers pay for the bagage like RyanAir: Less weight saves fuel.
And try to get a clean free slot at the desination: every holding pattern burns fuel!

And as some german students develop a "shark skin" that could save fuel,  it is just tested by Airbus. A 0.1 millimeter high structure on the wings.

So it's all about fuel.

Winni
Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 04, 2020, 07:19:17 pm
Save fuel is what the airline piolits get rated on. It's all buried in scheduling but the bottom line is fuel.

So I have tried a different shorter route. Phx to KME:

PHX Fri 03-Jul-2020 05:14PM MST to   MKE Fri 03-Jul-2020 10:42PM CDT
Actial Flight Time  3 hrs 28 min posted by the airline. This was in a Boeing 737 Cruise 523
 
It's 1458 miles div 8.71 = 167.393799 min or about  180 min / 3 hours. Factor in Taxi and decent and it's pretty close to the actual.



Title: Re: Problems with time and Distance Help Please
Post by: winni on July 04, 2020, 11:45:59 pm

So I have tried a different shorter route. Phx to KME:

Nice typo:

KME is Kamembe in Ruanda. Now inside the USA?

Sorry - I could not resist.
Good flight to Milwaukee!

Winni
Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 05, 2020, 04:11:51 am
No not a good flight.

This doesn't add up. The distance between PHX and KME is right on but the times don't make sence unless I'm doing something wrong.

The difference in this is the flight has landed in PHX, so the time of the airplane is  UTC Phoenix. but the departure time is wrong.
Title: Re: Problems with time and Distance Help Please
Post by: jamie on July 05, 2020, 02:23:13 pm
This thread is starting to remind me of the satellite tracking software I did years ago where I had to account for magnetic north , true north, elliptic arcs, LON,LAT, Accel etc..

Title: Re: Problems with time and Distance Help Please
Post by: winni on July 05, 2020, 03:02:59 pm

PHX Fri 03-Jul-2020 05:14PM MST to   MKE Fri 03-Jul-2020 10:42PM CDT
Actial Flight Time  3 hrs 28 min posted by the airline. This was in a Boeing 737 Cruise 523
 
It's 1458 miles div 8.71 = 167.393799 min or about  180 min / 3 hours. Factor in Taxi and decent and it's pretty close to the actual.

Don't believe the airline.
Do it on your own.
Allways the better solution:

  MKE Arr:   10:42
- PHX Dep   05:14
=                 05:28


The time offset between MST and CDT is -1.

So the real flight time is

04:28 hours


Same old story:
Calculating time with different time zones often confuses people.

Winni

Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 05, 2020, 08:34:24 pm
@winni
Often - It always confuses me.
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 05, 2020, 10:28:58 pm
Hi!

USA confuses me:

Phoenix has Mountain Standard Time (UTC−7)
Milwaukee has  Central Time (UTC−6/−5)

So: Milwaukee has now daylight saving.
And Phoenix has NOT.

So the time difference is -2 hours.

And so the flight time is

3:28 hours

Complicated America ...

Winni

Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 05, 2020, 11:36:54 pm
Ok - Hopefully this is correct. Needs verification Please.

Plane flew from KMKE to LPHX and landed. Over the ADS-B it transmuted it's locaton with a UTC time stamp of 1592610243.

So for PHX time convert  1592610243 to TDateTime and then to local time of 13:44:03.

The distance is 1458 miles or 11476 min. / 688560 seconds. Subtract 688560 from 1592610243 = 1591921683.

Convert the  1591921683 to TDateTime and then to Local time and I get:


MKE Local Time:    17:08:03
PHX Local Time:     13:44:03

Flight Time 3 Hrs and 44 min.

It close to what the SWA flight was?

JPeg and program attached.

 

 

Title: Re: Problems with time and Distance Help Please
Post by: TRon on July 06, 2020, 12:22:00 am
quick summary (by approximation):
flight time: 3 hours, 21 minutes
gate to gate: 3 hours, 44 minutes
speed 500 mph: 2 hours, 56 minutes
take off and landing: 30 minutes
distance: 1,464 miles = 2 357 km

current time (minus a few minutes, for me to post)):
time Milwaukee, Wisconsin:   5:16 PM on Sunday, Jul 5, 2020
time Phoenix, Arizona:   3:16 PM on Sunday, Jul 5, 2020
time-diff: 2 hours

so yes, you seem to be heading into the right direction  :D
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 06, 2020, 12:28:41 am
Hi !

No - I dont look into your code.
Airplane is landing before start time?

Start thinking!

Epoch time 1592610243 is 19.06.2020 23:44 :03
Then it was

-6 17:44:03 in Milwaukee
-7 16:44:03 in Phoenix

Winni

Title: Re: Problems with time and Distance Help Please
Post by: TRon on July 06, 2020, 12:31:02 am
Airplane is landing before start time?
Oh, my  :-[

Glad that at least someone is awake... I completely overlooked that part :-[
Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 06, 2020, 12:31:58 am
I don't get it ? Oh Yea I see it.

Well why isn't that working?
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 06, 2020, 12:37:34 am
Airplane is landing before start time?
Oh, my  :-[

Glad that at least someone is awake... I completely overlooked that part :-[

Hi!

Or we start that funny old discussion:

Is the speed of light a constant?
And is it related to the time?

Leaving with Warp  2:

Winni
Title: Re: Problems with time and Distance Help Please
Post by: TRon on July 06, 2020, 12:42:08 am
@winni:
Thank you for that ROFLMAO :)

edit: (you made me phase out of sync in such a way that I even spelled your name wrong, apologies).
Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 06, 2020, 12:43:46 am
I think I have the wrong offsets at both airports. Rechecking now.

Well to arrive before you leave would require a speed greater than the speed of light.

Yea I have the wrong offsets at both airports. However, after changing KMKE to -300 and KPHX to -400 I have the local time at KMKE at 19:28:03 and the local time in KPHX at 16:14:03.

The right elapsed time but arrival before leaving.

I don't know how to do this. Is there another way of solving the problem like a table lookup or something?

Title: Re: Problems with time and Distance Help Please
Post by: TRon on July 06, 2020, 01:45:33 am
I don't know how to do this. Is there another way of solving the problem like a table lookup or something?
I'm just a quick visitor of this thread (haven't read everything), you mean like a timezone database where you are able to look up the local time offsets ?

I had a quick look at what you posted a couple of message ago, and tbh I have not the faintest idea what you are trying to do there with all those static numbers.

As far as I was able to understand from your questions so far your inputs are:
- a lan/lat of an airport (obtained by airport callsign ?) where a departure of a plane takes place
- a lan/lat of an airport (obtained by airport callsign ?) where an arrival of a place takes place (preferably the same plane that departured in the previous item, otherwise we are already in trouble)
- you know the type of plane, therefor are able to obtain its (hypothetical) speed

Given those input parameters, you wish to:
- calculate the distance between the departure and arrival location
- calculate the (hypothetical) duration of the flight
- given either the arrival or departure time, calculate the departure or arrival time, both in their respective local time(zone), taking into account daylight saving time.

Is that what you are currently trying to accomplish ? or did I miss something there or expressed things wrongly ?
Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 06, 2020, 02:13:56 am
Yes TRon I think you got it right.

To be precise this is satellite tracking data. Several different providers sell subscription for live flights data (flights in the air).

What you get is the following:
opr  Dept  Arrv   Plane  EPOCH time    Lat         Lon         CallSign
AAL KMKE KPHX B787 1592610243   33.4333 -111.999  AA2164

That's it. The epoch time is for the Lat and Lon of the aircraft not for an airport.

There are two problems.  The aircraft may be en-route or landed.

What I need to do is determine the Local time at the departure airport and the local time at the arrival airport regardless of the position of the aircraft.

I have a file of 45,000 airports with the lat/lon timezone offset. In addition I have the FAA Aircraft designated table with all the airplanes of the world and there cruising speed.

The reason I hard codded all the figures was to post the data in a presentable form showing the calculations.

But, yes what you said is basically correct.


 The data comes from the ADS-B system


Title: Re: Problems with time and Distance Help Please
Post by: TRon on July 06, 2020, 03:19:23 am
Ok JLWest, then let's analyse what kind of information we've got so far (and I apologise in case it is perhaps obvious for you, but for good communication it is necessary)

What you get is the following:
opr  Dept  Arrv   Plane  EPOCH time    Lat         Lon
AAL KMKE KPHX B787 1592610243   33.4333 -111.999
No idea what "opr" is but, that is not important for us right now.

1) You have a call-sign (airport) for departure and arrival,
2) you have a lat/lon for the plane (wherever it might be located in the universe.. uhm.. I meant earth  ;) ).
3) to that lat/lon location of the plane, there is an associated epoch time.

Quote
What I need to do is determine the Local time at the departure airport and the local time at the arrival airport regardless of the position of the aircraft.
(*1)

Quote
I have a file of 45,000 airports with the lat/lon timezone offset.
That is an important piece of information on which things can be build.

Please correct me if wrong:
- For all 45,000 airports you have their respective latitude and longitude coordinates and additionally their timezone offset.
- I assume you are able to lookup this information, by using the callsign of the airport that you were given.
- That would mean you are able to determine lat/lon for departure as well as arrival location, complemented with their respective timezone offset.

That also means that you are able to approx. determine where the plane is situated (near departure or arrival location). But, we have to take into account that this means nothing, as a plain could f.e. fly its flight in the opposite direction of what you would expect (I have currently no idea how you would be able to detect that, as there seems a vital piece of information missing to be able to determine that. Feel free to express your thoughts on that).

Quote
In addition I have the FAA Aircraft designated table with all the airplanes of the world and there cruising speed.
As you already discovered with regards to your questions on the forum, you can calculate the approx duration of a flight by using that information, based on the lat/lon of the departure/arrival locations (again keep in mind flights flying in opposite direction is a possibility).

Assuming a flight always takes the shortest route (straight line) from departure to arrival location, you are then able to determine the direction of the flight (west to east, east to west, south to north, north to south and all in between).

Do take note that a plane flying a straight line is a myth, especially with countries/regions where there are airspace restrictions (and there are many of those, also in western peaceful countries).

Now, that poses a bit of a problem (at least for me) as I have no idea how you would determine, in case your data was taken when the plane was mid-air, when exactly the plane departured. It is simply imprecise without additional information. I expect you would comment on that...

(*1)
Have you taken notice of what winni tried to hammer into your ... uhm by lack of better wording, skull ?
1. convert plane epoch to UTC
2. use plane lat-lon to determine how long we've been flying since departure (lat/lon departure location, i.c.w. plane speed & taking into account other time-wasters during departure).
3. you subtract that time (2) from (1) to calculate UTC departure time.
4. you would then be able to calculate UTC arrival time

At this point you have all necessary data, only in UTC time and not in local time, for that we need the timezones (actually their offsets to UTC), and you would need to know if daylight saving time is active or not at the departure and arrival locations.
Local time = UTC time + timezone offset + DST (when active)

i.o.w. you use universal time as an absolute measurement, and after you're done calculating convert those universal times to their corresponding local times.

Does that make sense to you ?
Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 06, 2020, 04:34:19 am
"No idea what "opr" is but, that is not important for us right now."

OPR is the Carrier/Airline and it's not germane to the problem.

"I assume you are able to lookup this information, by using the callsign of the airport that you were given."

It's the Dept and Arr positions in the record.  Called IACO.

 " to that lat/lon location of the plane, there is an associated epoch time."
Yes
"- That would mean you are able to determine lat/lon for departure as well as arrival location, complemented with their respective timezone offset.
"

YES
"That also means that you are able to approx. determine where the plane is situated (near departure or arrival location). But, we have to take into account that this means nothing, as a plain could f.e. fly its flight in the opposite direction of what you would expect (I have currently no idea how you would be able to detect that, as there seems a vital piece of information missing to be able to determine that. Feel free to express your thoughts on that)."

These are scheduled airline flights and the fly from departure ICAO to Arrival ICAO. They are required to have a ADS-3 transponder encoded transmitter. It produces the EPOCH Time and Lat/Lon and the status (en-route, landed,started,unknown)

The information is picked up by a ADS-3 receiver located all over the world, thousands of them. They are a small Raspberry pie computer connected to a network. If the plane transmits a location that doesn't make sence it goes into unknown.

"Now, that poses a bit of a problem (at least for me) as I have no idea how you would determine, in case your data was taken when the plane was mid-air, when exactly the plane departured. It is simply imprecise without additional information. I expect you would comment on that..."

The end product doesn't have to be precise approximation is all that is required for the end use.  The end product will look like:

AAL KMEK KPHX B737 0950 AAL7854 N7456AA 2 1521  and this can be interpreted as American Airlines departing KMEK at 0950 local time to KPHX in a B737 flight AAL7854 FAA registration  number N7456AA on Tuesday at 1521 local PHX time.

This data will be used by a Flight Simulator X-Plane 11 to produce traffic en-route, parked at airports gates, taxing to and from gates and taking off based on the status of landed, en-route and started. The unknown are not processed (figure that one out and we could find MD-370 and Amelia Earhart)

Maybe 10,000 to 15,000  records will be produced. If some are completely wrong it's not that big of a deal.

Real-world airline schedules are computed  using approximate date. They add 10 min. for taxi out, 7 to 11 min to climb out, and maybe 15 min to descent and landing. Each carrier has their own standards.


"At this point you have all necessary data, only in UTC time and not in local time, for that we need the timezones (actually their offsets to UTC), and you would need to know if daylight saving time is active or not at the departure and arrival locations.
Local time = UTC time + timezone offset + DST (when active)

i.o.w. you use universal time as an absolute measurement, and after you're done calculating convert those universal times to their corresponding local times.

Does that make sense to you ?"

The airport offset is provided in the 45K airport file along with the Lat/Lon of the airport.

And I think I'm using UTC time throught the process except for the UniversialTimetoLocal function and DateTimeToString. PHX offset is -420

For  PHX I use UnisToDateTime to turn the EPOCH time into a TDateTime. At Phoenix all I have to do is turn the EPOCH time number into Local time UniversalTimeLocal then DateTimeToString.

For KMKE it's PHX EPOCH time 1592610243 - 688500
UnixtoDateTime then UniversalTimetoLocal and then DateTimeToStr. The offset of KMKE is -300.











Title: Re: Problems with time and Distance Help Please
Post by: winni on July 06, 2020, 09:19:32 am
"No idea what "opr" is but, that is not important for us right now."
...
 The offset of KMKE is -300.

* OPR is the abreviation for OPERATOR

* MKE is only in summertime time offset -300. In the wintertime it is -360. Daylight saving!!

Winni


Title: Re: Problems with time and Distance Help Please
Post by: TRon on July 07, 2020, 05:47:39 pm
Sorry for the delay.

Thanks for the additional information, also @winni.

Real-world airline schedules are computed  using approximate date. They add 10 min. for taxi out, 7 to 11 min to climb out, and maybe 15 min to descent and landing. Each carrier has their own standards.
I have left out the additional time 'wasters' for convenience (they can easily be added to the equation). Take that into account when looking at the results, e.g. earlier for departure later for arrival.

I quote myself
Quote
"At this point you have all necessary data, only in UTC time and not in local time, for that we need the timezones (actually their offsets to UTC), and you would need to know if daylight saving time is active or not at the departure and arrival locations.
Local time = UTC time + timezone offset + DST (when active)

i.o.w. you use universal time as an absolute measurement, and after you're done calculating convert those universal times to their corresponding local times.

Then, I quote you again:
Quote
And I think I'm using UTC time throught the process except for the UniversialTimetoLocal function and DateTimeToString. PHX offset is -420
I think you're not exactly doing that...

Quote
For  PHX I use UnisToDateTime to turn the EPOCH time into a TDateTime. At Phoenix all I have to do is turn the EPOCH time number into Local time UniversalTimeLocal then DateTimeToString.
You should not be using EPOCH time for PHX, e.g. it is not UTC. I believe that is where things go wrong with regards to your calculations.

Quote
For KMKE it's PHX EPOCH time 1592610243 - 688500
UnixtoDateTime then UniversalTimetoLocal and then DateTimeToStr. The offset of KMKE is -300.
... and again, EPOCH....

The problem is that the epoch time is not absolute with regards to the airports.

Try attached zip file, I believe that is what you would need in order to make the right calculations (I might be wrong though, so feel free to correct).

In case you wish to test it quickly using Lazarus then open a new project, with a form and place a memo onto that together with a button. Then copy-paste my code (minus the program header etc) and invoke procedure FlyingHigh() from a ButtonClick event. Don't forget to correct my code to use your memo. Or, compile the code using Free Pascal and start it from a shell/terminal.

Unfortunately I had only 2 items to test with (those that you posted in this thread), as I lack additional ADS records.

output:
Code: [Select]
Takeoff
Departure
    ICAO : KMKE
    name : General Mitchell International Airport
 lat,lon : 42.94720000,-87.89659800

Arrival
    ICAO : KPHX
    name : Phoenix Sky Harbor International Airport
 lat,lon : 33.43429900,-112.01200100

Flight
    ICAO : B787
    name : AAL AA2164
 lat,lon : 33.43330000,-111.99900000

Distance
 KMKE <--> B787 : 2345.584727 km (1457.546350 miles)
 B787 <--> KPHX : 1.211528 km (0.752843 miles)
 KMKE <--> KPHX : 2346.524925 km (1458.130588 miles)

Duration
 KMKE <--> B787 : 174.90 min (2.91 hour)
 B787 <--> KPHX : 0.09 min (0.00 hour)
 KMKE <--> KPHX : 174.97 min (2.92 hour)

Timetable
 Location   ICAO        UTC                     Local                   UTC+  DST+
 Departure  KMKE        2020-06-19 20:49:09     2020-06-19 15:49:09     -360    60
    Flight  B787        2020-06-19 23:44:03     -                          0     0
   Arrival  KPHX        2020-06-19 23:44:08     2020-06-19 16:44:08     -420     0
========================================
Departure
    ICAO : RJBB
    name : Kansai International Airport
 lat,lon : 34.42729900,135.24400300

Arrival
    ICAO : EHAM
    name : Amsterdam Airport Schiphol
 lat,lon : 52.30860100,4.76389000

Flight
    ICAO : B77W
    name : ??? ??????
 lat,lon : 63.62000000,38.28000000

Distance
 RJBB <--> B77W : 6947.509362 km (4317.182318 miles)
 B77W <--> EHAM : 2302.411254 km (1430.718353 miles)
 RJBB <--> EHAM : 9241.280512 km (5742.531710 miles)

Duration
 RJBB <--> B77W : 456.82 min (7.61 hour)
 B77W <--> EHAM : 151.39 min (2.52 hour)
 RJBB <--> EHAM : 607.65 min (10.13 hour)

Timetable
 Location   ICAO        UTC                     Local                   UTC+  DST+
 Departure  RJBB        2020-06-19 16:17:02     2020-06-20 01:17:02      540     0
    Flight  B77W        2020-06-19 23:53:52     -                          0     0
   Arrival  EHAM        2020-06-20 02:25:15     2020-06-20 04:25:15       60    60
Landing
Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 07, 2020, 06:50:02 pm
@TRon

Thanks, I'll Work the code up in a demo to see if it matches what I now have.
My offsets were reversed and the seconds were wrong along with miles per min.

But I can't trust the results. This is on the flight from KMEK to KPHX.

I'm departing at 15:23:30 and arriving at 16:44:03. It's about an hour and 16 difference. But then there is 2 hours difference between KMEK and KPHX. So then I'm wondering.

 "// JLW: The only time I have to work with is the Unix EPOCH 1592610832 at 63.62 Lat / 38.28 Lon.
  // JLW: The provider says the time is an Uniz/EPOCH time and is GMT, however it's really UTC. I think."

That's the only time I get is a Lat/Lon and a Unix/GMT but I suspect the time is actually UTC. However, that why I posted at the bottom of the form EGLL's (Heathrow) Offset. Heathrow is in the GMT timezone.







 
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 07, 2020, 07:11:41 pm
Hi!

Dont forget: There is summer on the northern hemisphere.

So London (Heathrow) is NOT UTC +-0 but with daylight saving UTC + 1!!!!!


Winni
Title: Re: Problems with time and Distance Help Please
Post by: TRon on July 07, 2020, 09:02:59 pm
Thanks, I'll Work the code up in a demo to see if it matches what I now have.
NP, and please take your time to see how I did things. In case of question then feel free to ask.

Quote
But I can't trust the results. This is on the flight from KMEK to KPHX.
Yours or mine ?  :P

I have no idea why you wouldn't be able to trust the results (whether they be mine or yours, unless we are still making an error somewhere)

Quote
I'm departing at 15:23:30 and arriving at 16:44:03. It's about an hour and 16 difference.
An hour and 16 difference between two different timezones. Look at my time-table for that flight, specifically at the UTC times. That is the real duration of the flight (well, theoretically).

Quote
But then there is 2 hours difference between KMEK and KPHX. So then I'm wondering.
Again take a closer look at my timetable if you will.

Code: [Select]
Location   ICAO        UTC                     Local                   UTC+  DST+
 Departure  KMKE        2020-06-19 20:49:09     2020-06-19 15:49:09     -360    60
    Flight  B787        2020-06-19 23:44:03     -                          0     0
   Arrival  KPHX        2020-06-19 23:44:08     2020-06-19 16:44:08     -420     0
UTC offset for KMKE = -360 min (= -6 hours)
UTC offset for KPHX = -420 min (= -7 hours)

But.... KMKE also has daylight saving active. so:
UTC offset + DST offset for KMKE = -360 + 60 = -300 mins (= -5 hours)
UTC offset + DST offset for KPHX = -420 +  0 = -420 mins (= -7 hours)

Which accounts for the 2 hour (virtual) time-difference between these two different timezones.

So, when UTC is 17:00 then that means it is 12 o'clock (local time) at/in KMKE and 10 o'clock (local time) at/in KPHX.

Would you fly an hour from 12:00 to 13:00 (based on timezone PHX) then the time in/at KPHX would be 11:00.

I have no idea what I could say in addition to that, in order to make things easier to understand. That is how time and timezones work.

That is why I calculate everything absolute to UTC, and only in the end convert those values back to local timezone (including DST). All times in the timetable which you can find at the column UTC actually makes sense in relation to the flight and other data. The local times however don't make any sense and can make your head explode  :D
(timezones/offsets are but a mere virtual/imaginary construct, and imho serves no purpose whatsoever other than screw with my internal clock for instance each and every time DST is (de-)activated).

My aim with the table was that you would be able to see everything with a single overview of all mentioned items. You should focus there on the UTC times, as they are the real true absolute date-time values.

Other than that, I had a quick view at the meaning of the words departure and arrival as used in aviation.

If you take a closer look at PHX arrival time, in relation to the Flight Time then you can see it is only a small distance/time-diff between them (1.2 km, about 5 seconds based on cruise speed). However, even though i have no idea what ADS records includes exactly, it would imho not be strange to assume that the last 5 seconds is not being flown at cruise-speed, rather it is the taxi from the run-way to the terminal. That would explain why it wouldn't be 'fair' to still add the 'waste'-time of descending, taxing etc to that arrival time (the plane is already busy 'performing' that 'waste' sequence). On the other hand you would have to account for that at the departure location, and would explain the difference between the/my theoretical calculation and actual flight information.

For the second test (Kansai - Amsterdam) you can see that, because of the ADS record that was taken mid-flight (and not at beginning/end), when you add additional 'waste'-time for departure and arrival the/my calculated times seems to make more or less sense in relation to the actual flight data.

Quote
That's the only time I get is a Lat/Lon and a Unix/GMT but I suspect the time is actually UTC.
tbh it was my first thought  ;)

If it wasn't then how would these ADS records look like for a 15 hour flight going through several different timezones ? Should you then use each lat/lon to determine the timezone, then calculate the absolute time to then calculate it back to local a timezone if you wish to work with the data from those records (for whatever purpose) ?

Imagine you have an airport located at the border of a timezone, the airport is busy and the plane circles around in its queue until it is it's turn to actually initiate landing sequence. Each and every time the plane circles around through different time zones. How would those ADS records look like if the epoch field was actually expressed in "local" time ? Pretty messy if you ask me  ;)
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 07, 2020, 10:19:58 pm

Quote
That's the only time I get is a Lat/Lon and a Unix/GMT but I suspect the time is actually UTC.
tbh it was my first thought  ;)


Hi!

I get lost among all those different datas - please give again the data of the flight Japan-Amsterdam plus the tempory Lat/Long and time of the airplane.

* What does the documentation say about the epoch time stamp of the airplane ?????

Winni
Title: Re: Problems with time and Distance Help Please
Post by: TRon on July 07, 2020, 10:51:01 pm
I get lost among all those different datas - please give again the data of the flight Japan-Amsterdam plus the tempory Lat/Long and time of the airplane.
I needed to construct that myself:
Code: [Select]
opr Dept Arrv Plane EPOCH time Lat     Lon    CallSign
??? RJBB EHAM B77W  1592610832 63.62   38.28  ????
It seems to be this flight: https://www.klm.de/flight-status/flight-details?date=20200620&originAirportCode=KIX&destinationAirportCode=AMS&flightNumber=KL0868

And I was able to collect the following information from that:
Code: [Select]
Departure
    ICAO : RJBB
    name : Kansai International Airport
 lat,lon : 34.42729900,135.24400300

Arrival
    ICAO : EHAM
    name : Amsterdam Airport Schiphol
 lat,lon : 52.30860100,4.76389000

Flight
    ICAO : B77W
    name : ??? ??????
 lat,lon : 63.62000000,38.28000000
The rest of my data are calculations based on that information. Feel free to retrieve your own to verify my airport data.

PS @JLWest: also feel free to post the UK flight RDA record, I get lost in your form-data  :-[
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 07, 2020, 11:19:51 pm
Thanks for the data.

If I put it all together I think the epoch time of the airplane  is UTC:

The Lat/Long of 63.62000000,38.28000000 is 100 km west of Archangelsk, Russia.
The epoch timestamp is 23:53 h

0:30 RJBB 20.06.2020  +9  UTC = 15:30   
Archangelsk                          UTC = 23:53
5:30 EHAM 20.06.2020  +2  UTC = 03:30

The time  delta to Dep is  8:23 h, the delta to Arr is 3:37h

That is a relation of  69% : 31%, which seems to be quiet right if I look at the map.

Winni
Title: Re: Problems with time and Distance Help Please
Post by: TRon on July 07, 2020, 11:42:48 pm
Thank you for the verification @winni.

This is what I was able to calculate from the information:
Code: [Select]
Timetable
 Location   ICAO        UTC                     Local                   UTC+  DST+
 Departure  RJBB        2020-06-19 16:17:02     2020-06-20 01:17:02      540     0
    Flight  B77W        2020-06-19 23:53:52     -                          0     0
   Arrival  EHAM        2020-06-20 02:25:15     2020-06-20 04:25:15       60    60

In that case, my calculations could work as a base which could be extended by (automatically) looking up the airport related data (location, lat/lon etc) from an external resource, as well as the airplane related information (cruise speed) and finally using a database in order to collect the timezone related information.

Then everything could be retrieved and calculated automatically from a single ADS record entry.

Which then would raise for me the question @JLWest, why you would want to do so ? e.g. would it not be easier to collect actual existing flight information and use that information for adding flights in your simulator ?
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 08, 2020, 01:07:09 am
Hi!

I don't want to spoil the party, but ......

For an intercontinental flight the airplanes take the route of the great cirle.  Ok - only a part of it which has a complicated name I forgot.

If you draw the great circle from Osaka to Amsterdam it will never ever touch 63.62,38.28
It goes much more north through the Kara Sea and Nowoja Semlja to get some radioaktivity from all the bomb tests. Then over the Barent Sea and then at the Atlanic side of Norway down to Amsterdam.

The only excuse is that there is no radar contact on the greatest part of the route.
So maybe they just compute just the current Lat and Long.
But the have not recognized that the earth is a ball.
Something like it ....

Winni

Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 08, 2020, 01:21:50 am
@TRon I have read the tables and data several times. It's impressive what you did.

 I worked last night on the KMEK to KPHX route.
  ICAO                 UTC                               Local                          UTC+  DST+
 KMKE        2020-06-19 20:49:09     2020-06-19 15:49:09            -360    60
 Arrival  KPHX        2020-06-19 23:44:08     2020-06-19 16:44:08  -420     0
========================================

KMEK                                                            15:23:30
KPHX                                                             16:44:03

The times are aa little different I think for 3 reasons. I'm using a different Haversine function than you. One supplied by Winni. My waste time is different and I haven''t figured out the speed you are using for either aircraft and we may be different there.

I can see the advantage of  staying in UTC time. I think it would be possible to to calculate these times if you had the following data points, which I do.

This is the data after parsing the XML record for a single flight. There are about 20 additional data points but nothing that I can use. Departure gate, arrival gate, IATA and IACO designations for everything. SWA is ICAO and IATA is WA doe SouthWest Airlines. A status of is landed and 0 is en-route.

SWA  B738  WN1747   N8574Z  1592610243  33.43330002  -111.9990005   KPHX  33.43427658  -112.0115814  -420   KMKE  42.94694519  -87.89705658  -300 status 1

"If it wasn't then how would these ADS records look like for a 15 hour flight going through several different timezones ? Should you then use each lat/lon to determine the timezone, then calculate the absolute time to then calculate it back to local a timezone if you wish to work with the data from those records (for whatever purpose) ?"

The ADS records would look like the one above regardless of it's position or time zone when transmitting. The data is collected and processed by the provided. He would get multiple transmissions from SWA  B738  WN1747 which is Southwest Airlines but he would only publish maybe one or two records. Maye an en-route and landed but usually one record.

ADS-B records contain altitude, heading, Speed in MACH I think but not all providers provide this. The provider I'm using doesn't. The fields come thru but they are almost always marked 'nul'. ADS data is pretty expensive.

"* What does the documentation say about the epoch time stamp of the airplane ?????" A note on that. There is a website that documents the ADS data. I went thru it and it's a little confusing.

I actually called the provide to ask about the time stamp. He said it was EPOCH/Unix GMT of the Lat/Lon position of the aircraft. He also stated it in an email. I looked and no longer have the email.

As for calculation in KM, meters I don't know anything about this scale. I would be glad to email my real name. You can look on the FAA website and check my pilot's lic. It is a Single engine, Commercial, Instrument rating with about 2,500 hours. The Gaiman 530, G1000, G750 and FMS are all done in miles and Flight Levels. Flight level FL350 is 35000 feet. I can and have programed all of those and I don't remember KM or meter in any. So that's why I did my calculations in miles.

An interesting thing about a U.S. pilots lic. It never expires, Once you have one it's good for life. It can be suspended for disciplinary reasons, but must have a time-frame with the suspension. You have to pass a physical every year to remain current. I failed my first physical 3 years ago and did not submit to the appeals board. I still have my lic. but it's not current.

 






Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 08, 2020, 01:32:54 am
No the airplanes fly the Skyways not the great circle. There are actual highways in the shy and they vary by elevation and direction. Those are the routes commercial airlines fly. They are called names like J124 or Q111, There is one that is call I40 like Interstate 40 in the US. In a few years they will no longer be used as planes will only fly way-points and do GPS instrument landings. A way-point is a location in the sky, not on the ground and with the current civilian GPS capabilities it is within 1 to 3 meters. Military is within 18 inches - 2017 .

Title: Re: Problems with time and Distance Help Please
Post by: winni on July 08, 2020, 01:42:21 am
Hi!

So there are nearly no problems left.
The distance can be computed because we have lat and long of the departure and the destination.
It is easy to convert them to out of time dimensions like mile or ancient greek Daktylos.

We have the time zone of the lift off and the touch down. So we can compute the time zone difference.

And for now we should not care about the third dimension:

From Phoenix to Milwaukee it is about 2.000 kilometer.
An airplane o an intercontinental flight is 30.000 fett high, that is 10 kilometer.
So that is 0.5%. That deviation is beararble.

Winni

Title: Re: Problems with time and Distance Help Please
Post by: TRon on July 08, 2020, 01:51:57 am
I don't want to spoil the party, but ......
Yeah, i saw that flight as well.... very strange indeed. Perhaps they were unable to get clearance for that day (in time) ?

Instead, take the flight from Tuesday, Jul 07 00:30. There you can see it is flying almost in a straight line from Osaka to Bejing, over Mongolia, then stays pretty close to the Kazakstan border (at least in comparison to that flight you mentioned), then in a  bow towards Finland. Just across the Finnish border (close to Baltic sea) the plane flies more or less again in a straight line to Amsterdam.
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 08, 2020, 01:55:55 am
Hi!

European and Chinese systems now have a better resolution than GPS.

You try to tell me that flight companies waste fuel?
I don't believe that.

But back to the facts:
If the flight data being near Archagelsk were true you should have seen KLM868 coming in over the Balic Sea way to Amsterdam. Not seen there.

But - as you can see on flightradar24 - the KLM from Okasa is on the great circle and has first contact to the european continent with the north norwegian airports.

Winni

PS.: Just seen on flightradar24

 
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 08, 2020, 02:17:04 am
Hi!

In the attachment KLM 868 flight.
Screenshoot reduced to get below the 250 k restriction to bad quality.
I tried to discuss that problem but they are all stuck in the 80s.

No - that is not a great circle. No, no ...

Winni
Title: Re: Problems with time and Distance Help Please
Post by: TRon on July 08, 2020, 02:49:50 am
The times are aa little different I think for 3 reasons.
There is a difference indeed.

Quote
I'm using a different Haversine function than you. One supplied by Winni.
You can swap the haversine function with whatever works best for you. I got mine from Rosetta-code and is based on KM's (I live in a decimal country  ;) )

Quote
My waste time is different
Correct, I have not accounted for waste time in my calculations/assumptions whatsoever. My code could easily be adapted for that though.

Quote
and I haven''t figured out the speed you are using for either aircraft and we may be different there.
Because I live in country where we work with the decimal system, everything I use is calculated in KiloMetre for distance and KiloMetre per hour for speed.

You can of course swap that out for mile and knot (or mile per hour) if you prefer.

Quote
I can see the advantage of  staying in UTC time.
If you would calculate with local times, e.g. needing to take into account the timezone offsets and DST's without using some sort of absolute reference, then you are for sure going to drive yourself insane  :)

Because UTC is exactly meant to be used as an absolute measure point, then why not (ab)use it for the purpose it was invented for ? (the ADS record using UTC by EPOCH is there for a reason  ;) )

Quote
There is a website that documents the ADS data. I went thru it and it's a little confusing.
Feel free to share in case its public accessible. So far, I was unable to locate any documentation with regards to those records (but I haven't had a good search for it yet either)

Quote
I actually called the provide to ask about the time stamp. He said it was EPOCH/Unix GMT of the Lat/Lon position of the aircraft. He also stated it in an email. I looked and no longer have the email.
Although I am far from knowledgeable on the subject, that sounds like rubbish.

That would really be unworkable if the data inside their database (ADS records) would contain an epoch timestamp based on the timezone/DST that corresponds to the lat/lon coordinates of that same ADS record.

Any data should be normalised before it can actually be used in a useful manner. If they won't do that for you, then it beats me why they ask such ridiculous prices for these datasets. (yes, i have been looking around, even for a simple (public knowledge) airport database and (public domain) timezone database they dare to trick you into a subscription service and bill you indefinitely with ridiculous amounts of number of request that you are allowed to perform per day/week/month).

Quote
I can and have programed all of those and I don't remember KM or meter in any. So that's why I did my calculations in miles.
No problem, it is all public knowledge. I do not know anything about knots and miles so had to look that up in order to calculate things in units that I am able to understand, so I guess that makes us even  :D

In case you require help with that then feel free to ask. It is pretty easy to convert my code to work with knots and/or miles, although I personally do draw a line with measuring distances in inches.

1 Kilometre = 0.6213712 Mile, meaning 1 Mile = 1.609344 KiloMetre.

I used names for the conversions-constants inside my code and therefor should be self-explanatory ?

Quote
You have to pass a physical every year to remain current. I failed my first physical 3 years ago and did not submit to the appeals board. I still have my lic. but it's not current.
I'm sorry to hear that. I take it that is due to age related (health) issues ?

At least I do hope they won't expect you to run the 100 metres within 10 seconds in order for you to keep your license. I would have failed such a test myself ages ago  ;D
Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 08, 2020, 02:51:22 am
They are a;; great circle. Back i the day that's what they called it. Now their International Routes.

And no China doesn't  have a better system. Military GPS accuracy is reportedly down to inches, less than 12. Instrument landing come in 3 flavors. Cat I, Cat II and Cat III. Only the military lands Cat III. Cat III is zero visibility. Airlines can't do this for two reasons. The FAA won't allow it and if they landed in zero visibility how would they taxi to the gate. They would have to be towed. So they are required to have enough fuel to fly to their secondary and 45 min additional fuel.

"I'm sorry to hear that. I take it that is due to age related (health) issues ? "

It's due to eye sight. Stable but not repairable. My computer screen is a 50 1080 and I sit 6' from it and still have dificulty seeing the screen.
Title: Re: Problems with time and Distance Help Please
Post by: TRon on July 08, 2020, 02:53:02 am
In the attachment KLM 868 flight.
Screenshoot reduced to get below the 250 k restriction to bad quality.
I tried to discuss that problem but they are all stuck in the 80s.

No - that is not a great circle. No, no ...

Winni
Yes yes, that is the one that is weird. I was referring to https://www.flightradar24.com/data/aircraft/ph-bhe#24d390ac which looks much healthier to me.
Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 08, 2020, 03:07:49 am
"Because UTC is exactly meant to be used as an absolute measure point, then why not (ab)use it for the purpose it was invented for ? (the ADS record using UTC by EPOCH is there for a reason"

Yes there is a reason. There are ADS receivers all over the world. Hundreds of thousands of them. They are the size of a shoe box, a Raspberry Pi computer inside connected to the web and powered by 110v or a battery. Most are privately owned and they supply data to the providers. For a provider to have worldwide coverage would require an hardware instantiation at about 90,000 airports.
 
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 08, 2020, 03:28:03 am
Hi!

The newspapers told that Russia got mad about Corona and did not allow any international contact, especially by flight. Now they have checked what a nonsense that is and stopped it.

There is no clear order about the situation.

But: it seems that TRon got a flight that did not touch Russia. And I got one that took the normal route.

Good night
Winni


Title: Re: Problems with time and Distance Help Please
Post by: TRon on July 10, 2020, 10:20:28 pm
Would you be able to share more with regards to the status field in those ADS-B records ?

I've done some research and the message as you described does not seem to be a standard S-record so your supplier seem to use some custom format.

There is even more to it than that, as this particular flight, flight WN1747 from Milwauki to phoenix @ June 19th, seem to have some particularities (but perhaps that is why you choose to use this flight as an example)

This flight was scheduled to depart from Milwaukee at 19 jun 20:20 UTC (15:10 CDT), but in fact departured at 15:14 CDT (4 minutes late)

This flight was scheduled to arrive at Phoenix at 19 jun 23:50 UTC (16:50 MST), but in fact arrived at 16:42 MST (8 minutes early).

The (EPOCH) timestamp of the S-Record message is 19 jun 23:44, thus recorded two minutes past arrival.

Quote
There are about 20 additional data points but nothing that I can use.
So you say. No reason to doubt that statement but I do wonder.

Because your supplier seem to have a mind of its own about what should and shouldn't be part of those records, things could become messy.

Right now it looks more to me that your supplier witholds (vital) information either because a) your supplier hasn't got those informations to begin with and/or b) attempts to squeeze you out for even more money in case you do wish to obtain the actual information.
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 10, 2020, 10:31:38 pm
Hi!

Those supplieres are allways greedy. There could be the big money! If you are a buisiness client and need ALL  data plus more than a 5 digit number of flights you really pay a hell.

I also recovered by checking by myself that the great cirle from Osaka to Amsterdam does not go so wide North like my screenshoot. It should come down way over South  Finnland, then South Sweden way  to Amsterdam.  Don't know what strange things KLM did that day.

Winni
Title: Re: Problems with time and Distance Help Please
Post by: Thaddy on July 10, 2020, 10:46:29 pm
Those supplieres are allways greedy.
Winni
It is the other way around.
Even if data as such is in the public domain, you can not simply copy data from a publisher that invested money to show that data. That's theft.
Not the data itself, but stealing from its presentation.
That is a crime in the European union.

On topic: ADS receivers rely on a simple protocol which is open , so why all the fuss? just do it yourself.
Title: Re: Problems with time and Distance Help Please
Post by: TRon on July 10, 2020, 10:56:14 pm
@winni:
Yes, indeed. I have noticed that as well. Most websites/suppliers are so greedy that they not even realise what nonsense they sell.

Even the project that JLWest refers to, the pi's (or so called feeders) that 3th parties use to supply the data to certain websites expects to be payed big numbers, or you must become a feeder (but even then some requests seem to be restricted).

Don't get me wrong on that, as I do understand why as certain commercial entities think it is a good idea to 'borrow' the data (by the millions) from such websites so resell them for big bucks again. The project that JLWest referred to was such a victim, and therefor they made the decision to almost not share anything anymore unless you are an actual registered feeder.

With regards to the Osaka - Amsterdam flight: Yeah, there seems to be something strange that happened that day. Of course it is always possible there was some sort of NATO exercise or some temporary air-space lock (as you suggested) or perhaps something else going on that day that prohibited airlines to use their normal flight-plans. I have no idea, as aviation isn't really my thing.

@JLWest: with regards to take-off. You said you used a standard time-frame for that to calculate your data, but I have come to the conclusion that this number you used is way too optimistic. If you look at the actual flight data from that Phoenix flight then you can see that reaching altitude and therefor optimal cruise-speed took over 15 minutes for that plane to actually realise on that flight. I would love to share this data but I forgot to make a copy of it and now I seem unable to locate it anymore as most of those websites only keep track/storage of such data for a couple of days/weeks
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 10, 2020, 10:56:38 pm
Hi!

Which way round it is - might be a great discussion.

But who punishes it?

Like MP Gerhard Schröder violated international law by starting  the war against Serbia. The first war of aggression since Adolf Hitler. A socialdemokrat and  a green foreign minister. 1999.

Nobody cares.

Winni
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 10, 2020, 11:05:12 pm
@winni:

With regards to the Osaka - Amsterdam flight: Yeah, there seems to be something strange that happened that day. Of course it is always possible there was some sort of NATO exercise or some temporary air-space lock (as you suggested) or perhaps something else going on that day that prohibited airlines to use their normal flight-plans. I have no idea, as aviation isn't really my thing.


Hi!

Just had another idea - a press note that was mostly hidden:
In Western Russia there was extended radioactivity.  They measured in in Skandinavia but it was not dangerous. So nobody cared about  it. Maybe the Russians knew more than we and closed the airspace?????

Winni

Title: Re: Problems with time and Distance Help Please
Post by: TRon on July 10, 2020, 11:19:04 pm
On topic: ADS receivers rely on a simple protocol which is open , so why all the fuss? just do it yourself.
1. I don't think if I would install such a receiver that I am able to to receive all data from all flights from the whole world. Not sure, but an educated guess  ;)
2. I wanted to make sure user JLWest understands that his supplier isn't providing the actual data that comes from these transmissions, it seems to be an excerpt of it.
3. There is no fuss other than user JLWest picked two flights for us to work with and both flights seem to have something strange (or at least out of the ordinary) going on.
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 10, 2020, 11:37:57 pm
Hi TRon!

All those "airplane providers" try to convince you to install a ADS reveiver at your window board and send the data to the "Big Boss". Here and then I look flightradar24 and they also try to convince everybody. So they might get more detailed data from a city or even got one one sender at the end of the world ( Australian Outback, North Norway, Greek small Islands ....).

There might be some deviations because of windstorm, political reasons ...

BUT JLWESTs results are sometimes astonshing.
The first he should clean up his form with 87 labels. I allways get lost there .

Winni
Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 11, 2020, 02:21:48 am
Yea I can get better data at about $1,225 a month with a yearly subscription. The absolute best ASD-B data is with Cirium and/or maybe OAG. Both have excellent selection of API Calls and provide great data. The one I use is third tier. But the project is for someone else. I'm just doing the work for WT3.

No good deed goes unpunished.

As for ASD-B receivers, they run on a Raspberry Pi computer  connected to an antenna and to the network with an open source of specialized code. They are line of sight with a range of 25 to 30 miles. Therefore the providers needs a bunch for worldwide coverage. One near every airport. The provider makes money two ways. Selling the data and a fee if they will omit certain NS and military flights from their data. As I understand it, yea. There is one provider that will provide all ASD-B data raw, unfiltered. but you can't use it in a commercial product.

Because  this data is going to be used in a Flight Simulator product (X-Plane 11 and World Traffic-3) we don't have to be that accurate.

Title: Re: Problems with time and Distance Help Please
Post by: TRon on July 11, 2020, 04:18:07 am
Yea I can get better data at about $1,225 a month with a yearly subscription.
*ouch*

That is no fun for a hobbyist such as myself.

Quote
No good deed goes unpunished.
Seems that way  :)

Quote
Because  this data is going to be used in a Flight Simulator product (X-Plane 11 and World Traffic-3) we don't have to be that accurate.
Of course, only you can be the real judge of that. I only report what seems to be obvious for/to me.

For instance, and afaik (which isn't much) the ADS-B 'status' doesn't know anything about a status such as "landed". It is however able to provide information whether a message originates from the plane being "on-ground" (indicated by a one) or not (indicated by a zero).

Therefor, when a message is being indicated as 'on-ground' then, in order to determine whether the 'waste' time should be compensated at time of departure or arrival you should use the distance to either of those two locations and determine which position is closer to the plane's current position.

But there we have the problem that we do not know which exact part of the 'waste'-time should be added to the departure or arrival because it depends whether or not the plane has already partaken in a specific action (that belongs to the waste-time) or not (and for how long the plane is already doing so).

Perhaps minor details but, for sure has a bigger impact when just fumbling around.

Right now, with the information provided, it is just a pure guessing game which (waste) time should be added where exactly. (and I am sorry for keep calling it waste, as I simply lack better wording for it so that it depicts both departure and arrival locations activities done before the plane is actual cruise-flight state).
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 11, 2020, 06:51:10 pm

But there we have the problem that we do not know which exact part of the 'waste'-time should be added to the departure or arrival because it depends whether or not the plane has already partaken in a specific action (that belongs to the waste-time) or not (and for how long the plane is already doing so).

Perhaps minor details but, for sure has a bigger impact when just fumbling around.

Right now, with the information provided, it is just a pure guessing game which (waste) time should be added where exactly. (and I am sorry for keep calling it waste, as I simply lack better wording for it so that it depicts both departure and arrival locations activities done before the plane is actual cruise-flight state).

Hi!

If you really want to know the second of the lift off and the touch down you need the exact height of the airplane.
That info you get either direct from the plane or from the tower.

Even a page like flightradar24 often has often the same symptom:
The plane  starts the approach for landing - and suddenly it is stuck at some hundred feet height:

It vanished behind some hill and you will get no info anymore until it moves on a runway.
So with little money you will never get exact data.

So we will have to do some rounding - as near as we can assume.


Winni
Title: Re: Problems with time and Distance Help Please
Post by: JLWest on July 11, 2020, 07:13:31 pm
ASD-B data comes from the transponder in the plane. It transmits the ASD-B periodically, not constantly like the transponder setting. The receivers have a line of sight 20, 25 mile range. ASD-B was never meant to give accurate location information. However, they do transmit Lat/Lon altitude, speed and heading information. I just have a lousy provider. When the Transponder was turned off in flight MD370 his location was no longer reported on ASD-B. But there is no receivers in Indian ocean anyway.

   
Title: Re: Problems with time and Distance Help Please
Post by: winni on July 11, 2020, 07:24:45 pm
Hi!

There are a lot of "blank" area with no receivers. Take the center of Afrika: nobody knows where you are.

The Indian Ocean is indeed poor. In the north you got some holiday islands plus Diego Garcia Base, owned by GB but used by USA. There they started the bombers to the Iraq.

But between South Afrika and Perth in Australia there is really nothing. That's where they search for the lost malayan flight MH 370.

Winni
TinyPortal © 2005-2018