KML tracks "last / first seen" coordinates at N00, E00. Heliport landings / takeoffs missing

FlightAware Feature Requests and Ideas
1

New to these forums.
My feeder is about 14 miles from a small rural airport with a surprisingly high General Aviation traffic count.

There are also several hospitals in range from which my feeder has captured numerous medical flights. Due to curvature of the earth and buildings, the signal is usually lost at about 80 to 150 feet AGL as it drops below the building height.

Most of these flights, when viewing / downloading KML files of their tracks, indicate “invalid” or “last seen near” when the final position report was obviously on final approach to one of the runways and a extrapolation inside Google Earth Pro of the KML track on the same bearing and slope intersects the ground right in the middle of the runway or at a hospital helipad.

However, the KML tracks downloaded from FlightAware in these cases appear to create an “airport” in the Atlantic Ocean off the west coast of Africa N00 00 000, W000 00 000 when I open these in a text editor or load them into Google Earth. This makes the Google Earth globe spin almost halfway around the world when these tracks are loaded.

  1. Is there a plan to add hospital and other heliports to the database to properly account for these off-airport flights?
  2. could the point tag in the KML track on these kind of flights just put the stick pin at the last known coordinates instead of make an “airport” stick pin in the KML in the middle of the Atlantic?
  3. If the last flight position heard was clearly on final approach to a runway, on a bearing within a couple of degrees of the runway and at an altitude trending a descent that extrapolation would clearly result in contact with the runway, is it possible to more quickly convert it from “en route” to an “estimated arrival”?

Many of the general aviation flights are pipeline / oil field leak patrols departing from and arriving at 7T7, end up showing as “en route” well over an hour after their last heard signal. It is obvious (well, to me, with some GIS processing experience and a few amateur radio APRS based high altitude balloon payload recoveries) that the aircraft is on the ground and has been there for a while.

Detecting a full stop landing in these circumstances should be possible to be assumed via algorithm when the aircraft was last heard from on final approach, hours before the track finally resolves now to either an estimated arrival or a “last seen near” end.

Back to the helicopter problem, a database of known heliports would provide much more accurate flight data on these. I pinpointed 3 in a few minutes manually by editing KML tracks downloaded from N911LL on a trio of flights and adding extended segments then zooming in on where those crossed to find the heliports.

The first leg is
https://flightaware.com/live/flight/N911LL/history/20210302/1944Z
which thinks it landed at Lea County Industrial Airpark (NM83). However, it actually landed at 32°45’44.50"N 103°11’11.93"W
This is close enough to NM83 for confusion to reign.
It then took off for Lubbock, which was recorded here:
https://flightaware.com/live/flight/N911LL/history/20210302/2052Z/NM83/L%2032.72664%20-102.65300
There is a gap in the data which accounts for when the helicopter was clearly on the ground, based on altitude and terrain elevation as well as speed at the positions immediately before and after the gap in data.
Had there been a feeder on the Texas Tech campus on a mid to upper floor of the high-rise dormitories right across the street from this hospital, it would have gotten positions on the ground at Lubbock Covenant Hospital, at one of the two helipads at 33°34’36.45"N 101°53’24.81"W

However, the track did not break this into two separate flights, and combined the trip from Hobbs to Lubbock and Lubbock back to Seminole as a single flight.

ed to add after I made this post, the same helicopter flew the same route again, but it is now broken into 3 flights.
https://flightaware.com/live/flight/N911LL/history/20210303/1538Z
Seminole to Hobbs leg, origin and end at hospitals
https://flightaware.com/live/flight/N911LL/history/20210303/1705Z/NM83/KLBB
Hobbs to Lubbock leg, origin and end at hospitals, with stop at KLBB apparently for fuel
https://flightaware.com/live/flight/N911LL/history/20210303/1759Z/KLBB/L%2032.72488%20-102.64955
Final leg, destination hospital at Seminole.
Most of the flights of this specific aircraft over the past few days, N911LL, have originated and ended at Gaines Memorial Hospital 32°43’14.33"N 102°39’17.92"W.

This might be a good specimen flight, cluster of helipads, and aircraft for people poring over how to code such a thing to work with.

2

Here is another flight which, due to proximity to my feeder and others at the hospital end, captured an excellent pair of points right at the ORMC helipad.

https://flightaware.com/live/flight/N427PH/history/20210301/0906Z/KPEQ/KPEQ
Notice the length of the gap in data at the middle during the round trip.

This was apparently on the ground at the ORMC helipad at 31°51’10.36"N 102°21’49.57"W
https://flightaware.com/live/flight/N427PH/history/20210301/0906ZZ/KPEQ/KPEQ/google_earth

The KML file shows these two lines highlighting the gap in the data, which is a reasonable approximation of the time the helicopter was on the ground
2021-03-01T09:49:31Z
2021-03-01T10:21:55Z
which correlates to
gx:coord-102.36412 31.85275 846</gx:coord>
gx:coord-102.37744 31.85411 1196</gx:coord>
in the track points.

By contrast, here is yet another flight that made two off-airport stops (hospitals) along the way, which exports a KML with two placemarks in mid-Atlantic.
https://flightaware.com/live/flight/N911LL/history/20210304/1617Z
I looked closely at this, and realized a really quick fix might be to just omit the following from such exported KML files:

(code snippets to display text verbatim instead of attempting to render is apparently not supported on this platform)
Essentially it is a “placemark” section with a name of INVALID Airport, and coordinates of ,0

This appears to be what makes exported KML files “break” from flights whose origin / destination was below the radio horizon of any feeder, or where the origin / destination is actually off-airport, as frequently occurs with helicopters.

Nothing in any normal KML file generated from other GIS data should have zero or blank coordinates, because Google Earth will merrily attempt to display points on the intersection of Prime Meridian and Equator whenever a file containing these are loaded.

I could probably write a Python script to parse the files and explicitly find and remove these placemarks before sending the cleaned up version to Google Earth, but it really should be fixed at the source.

On that example flight, I edited the file and inserted coordinates for both of the hospitals that it stopped at - Lamesa and UMC Lubbock, placing the coordinates for the helipad a minute after the last point before the missing data areas began, and the result cleaned up quite nicely.

So I think I found the actual bug - placemarks in the exported KML files that translate to points at the Prime Meridian and Equator off the west coast of Africa in the middle of the Atlantic Ocean. If those can simply be dropped from the exported KML files, they should all render quite nicely when brought into Google Earth.

Then the next really cool improvement would be eventual support of helipads. Headed back to tweak the thread header closer to the true nature of the primary bug.
Thanks in advance for whoever does coding on the platform, picks this up and fixes the bug.

3

With respect to heliports/helipads, better support for them in general is on our roadmap. As you note, we generally tend to avoid departing/arriving flights at heliports to avoid the opposite problem (i.e., departing/arriving a fixed wing flight at a heliport). Due to the overall quality these days of our ADS-B network, we are able to get a lot more surface positions, so there are opportunities to support heliports better when our ADS-B coverage allows it.

4

It seems like getting good surface positions is mostly a geometry problem - feeder location close enough to these LZs that the antenna is above the radio horizon of these points. Picking optimum sites can then be done with readily available tools such as Google Earth, a GPS, and the ARRL Handbook.

Do all ADS-B units transmit “on the ground” frames when they decide the aircraft is actually on the ground, or is this an expensive option that mostly restricts it to large commercial aircraft and very well heeled GA operators? From a technical standpoint, it seems to have no real cost other than a few more lines of code.

My guess is that they look at speed and rate of climb and descent and elevation, and when the horizontal and vertical movement vectors approach zero, it switches to beaconing “on the ground” frames, and finally “stopped on the ground” once the speed has been at zero for longer than so many seconds or minutes? If it has the field elevations of all the airports in an internal database, then it could also look for coordinates within a sampling error bubble that places it on the surface of the airport, at a speed some percent below V(so) for the aircraft and effectively zero rate of climb or descent. At least if I were to start with a blank page to design an algorithm to detect this condition, that would be how I would rough out an initial flowchart.

In 2017 some of us used a similar technique to better pin down the ground impact point of a high altitude weather balloon payload. Essentially we gave it an average terrain elevation floor. Above that floor, it used the ham radio APRS beaconing rate and path specifications for an object with a very far radio horizon to avoid flooding the network with digipeated packets. Below that floor, it switched to a beacon path that normally is only used with cars and such to improve the odds that a chase and recovery team still 40 or 50 miles away could possibly capture coordinates of the payload within 100 feet of hitting the ground.

It worked quite nicely, although not critical on that particular launch because I was almost directly under the payload and barely 1/8 mile from the point of impact, and then heard it directly after it was lying on the ground, making the final recovery effort similar to geocaching.

If all ADS-B equipped aircraft send “on the ground” beacons from when they land until the master switch is turned off after parking, then it seems that a feeder actually on the airport grounds would pin these down quite reliably. A feeder at a major hospital would thus easily get “on the ground” frames from helicopters from the moment it lands until the crew shuts the engine(s) down and turns off the master switch, then again from the moment the master switch is on and the engine start checklist begins, up until actual lift-off from the pad.

I guess I need to rig up a portable PiAware unit that can be just left with someone who works at the hospital, where they can leave it running in their car during their shift, as the parking lot is adjacent to the helipad. Let them keep it for a couple of months, and see what it captures. Or better, find someone in the hospital administration who would be willing to just set up and maintain one somewhere on the hospital grounds to run 24/7.

That wouldn’t need to even do real MLAT functionality, as its main job would be to get the last mile of medical helicopter arrivals and departures.

Same for more remote GA airports. A PiAware operated and maintained by someone that was, say ,on the roof of a hangar overlooking the FBO fuel area ought to feed all of the surface operations quite nicely, especially if it used an attenuator to keep the strong close proximity signals from overwhelming the SDR front end.

5

Generally, no. There’s an involved set of rules (and many different implementations of varying quality) but the short version is that for aircraft without a weight-on-wheels sensor or equivalent, you may not reliably see ground positions. (And even with a WoW sensor, you get errors in both directions)

6

That was one thing I wondered about. While an A-380 probably has this, the average 1963 model Cessna 172 operator would likely find this modification’s paperwork and cost burden to be prohibitive, based on my experiences with that way back in the 1970s / 1980s. Unless one has an Experimental category aircraft, where one could do some cool early adoption of new things to put in the LongEze or BD-5 with far less expense.

I need to sift through the rules to see if there’s possibly some way to come up with an algorithm to infer a probable landing from the data available. I’m thinking it would require a receiver in close enough proximity to the presumed landing spot to get final positions and analyze the trajectory, possibly a lookup table of aircraft performance capability to observe “this is moving well below stall speed, and at an elevation within the uncertainty bubble of sitting on the ground, and has not exited the geofence of the airport or heliport”.

That might be like
if “more time has elapsed than the fuel endurance of this aircraft”, && “the last known position was within the GPS uncertainty of the runway surface” && "last speed heard was well below V(so) " then “mark it as landed”

7

More gripes and a couple of workarounds.

  1. Get rid of (or fix) all constructs in the KML file which do not contain real coordinates. I am tired of having the globe whip around to mid-Atlantic (N00.000 W000.000) when I’m zoomed in somewhere in the middle of the New Mexico mountain wilderness and open a track to overlay. That is very bad programming practice to put any kind of bogus data in these files. No. Just no.
    My workaround:
    Presently I just use SED (Linux box) to do a global search and destroy and remove the bogus placemarks.
    This blunt instrument method keeps the Google Earth globe happy, which to me is the most important thing.

A more elegant solution is to insert the first or last coordinates of the GPS track into the existing bogus “airport” already being inserted into the KML file.
I am working on a more elaborate Python script to go through a few thousand files I have saved to fix this with my archived tracks.

  1. Departures from “first seen near” with arrivals at actual airport lack proper arrival placemark in KML, or proper arrival field in filename.

Example:

https://flightaware.com/live/flight/N910GX/history/20211010/0953ZZ/google_earth
produces a filename of
FlightAware_N910GX___20211010.kml

The KML does not reflect that this clearly landed at KPEQ. A properly formatted filename should, to be reciprocal with departures from known airports with unknown arrivals, as
FlightAware_N910GX_INVALID_KPEQ_20211010.kml

My workaround:
I built my own KML file of all the area airports, including some private strips not in the official FlightAware site but in FAA records.
I name the file like above based on the stated arrival airport, then edit it as in 1., but then drop in the correct placemark for the arrival airport rather than just completely delete the bogus placemark. This keeps the naming convention consistent.
The rare tracks that both depart and arrive off-airport, I re-assign a filename that includes INVALID_INVALID.
These are common for medical helicopters based at hospitals more than a mile or two from the nearest traditional airport.

  1. Please change the default to append the timestamp to the date stamp portion of the filename. Many aircraft make more than one flight between the same places on the same day.

My workaround: When saving the file, I just add an underscore after the yyyymmdd field, followed by hhmm and finally z. But it would be very convenient if FlightAware did this by default.

Thus in the example at the top,
FlightAware_N910GX___20211009.kml
becomes
FlightAware_N910GX_INVALID_KPEQ_20211009_0953z.kml
and this repaired file will open properly on Google Earth, it doesn’t have points in mid-Atlantic on the equator any more, and you can tell something useful from the filename alone in a directory listing.

A file naming improvement for easy sorting on most operating systems. Move the date and time stamp fields in the filename to immediately after the tail number.
This will naturally group flights by the same aircraft into chronological order no matter where they departed or arrived.
This makes a natural itenerary of the aircraft visible by just looking at the directory listing with most GUI based operating systems.

tl;dr
Just fix these issues with the KML files - starting with #1 priority - lose the equator / prime meridian intersection placemark points. Just get rid of those. Very unhelpful junk in a KML file.

Next priority - fix filenames and internal data to handle off-airport departures followed by on-airport arrivals. Put the on-airport arrivals in the filename and placemarks in the files even if there was an off-airport “departure”. There are still quite a few FBOs and small town airports too far from any feeders for actual arrivals and departures to be observed and logged.