v0.0.32 Runway Position not calculated from updated threshold.xml Data

[BecOzIcan]

• LIMC
• Runway Location in APT DAT is misplaced
• Valid Threshold Positions recovered from AIP Italia and updated via groundweb upload
• Re sync'd FGA and Thresholds now show in correct position on OSM background

BUT

• Final Node of Route ending in Runway fails validation as FGA consider it is not in runway, despite being between thresholds

AND

• If I make it "not on runway" then if returns an invalid end error and AI aircrafts cannot take off from this THR.

This means I cannot pass validation at all for this groundnet nor use this runway

EXPECTED: Runway position for the purpose of deciding which nodes should be marked "on runway" to come from ICAO.threshold.xml file if available OR Node on Runway Errors do not block validation (Warning Only) but this is the least preferred option

[BecOzIcan]

Please note the TRAVIS Tests do not seem to be aligned : I submitted via groundweb with nodes on runway as per THR data and file passed all tests. No complaint here !

[Portree-Kid]

Travis doesn't know of runways yet. This can be changed if ICAO.thresholds.xml is the single truth.

[BecOzIcan]

All good then. Actually not a bad thing to have this 'backdoor' on the travis/groundweb upload side.

And separately, get FGA to work out runways positions from thresholds so we can cater for discrepancies in APT DAT

[Portree-Kid]

How important do you regard the runway width? The threshold file doesn't contain it and therefore I would need to rely on apt.dat or I just assume 20m

[BecOzIcan]

As far as I understand it, Traffic manager only uses the final/first node of the routes finishing/starting on runways so 20 meters would definitely be good enough as I trust we all place these "final nodes" close to the runway centreline

[Portree-Kid]

Maybe better just draw it as a red box 10m wide. It would show it isn't actually not a "runway" but rather a "takeoff box".

[BecOzIcan]

Sounds like a very good solution to me

[Portree-Kid]

Prototype

[BecOzIcan]

Yes although I would keep it a simple black contour and no hashing as, visually

• It is a simple extension of the thresholds icons (moves/rescale with them)
• It is not related to the APT DAT elements like centreline and pavement which use the grey/yellow color scheme.

[Portree-Kid]

Yes sounds fine.

[Portree-Kid]

The check for runway nodes needs some thought. If we think of APT.dat runways being misplaced it must be in takeoff box OR on APT.dat runway.

[BecOzIcan]

In current code, the aircraft will not initiate take off until it has reached an end or route AND this end of route is marked as "on Runway" AND this end of route sits within the two thresholds.

This means in the example above, we only need the last node (Left of threshold icon) to be marked "on runway", all other will be discarded as acceleration/take off points.

In short, the functional relationship of the "on runway" nodes is to the thresholds, not to the APT DAT runway although Traffic Manager somehow still "sees" the APT DAT runway in absence of thresholds as mentioned by Gooneybird in the "disused runways" post.

Again from the example above, if you wanted the AI traffic to stay on the misplaced APT DAT runway, you would simply need to relocate the thresholds and the "on runway" test logic would simply follow them.

That is, when it comes to groundnets functional validity (and FGA Automated Tests) as well as the ability for traffic to arrive/depart we do not care about the position of the runway in APT DAT although I totally understand it is nice to have aircrafts actually using runways and not roll on grass but linking "on runway" to thresholds still allows us to do that by relocating thresholds on an ad hoc basis

Or maybe I am totally missing your point? Feel free to elaborate.

[Portree-Kid]

No fine. Even though I'm knee deep in the AI code I was unsure there was any ATC runway clearance implemented.

[gooneybird47]

When I started doing groundnets I was told (by Durk I believe) that the only nodes that needed to be set as "on runway" were the final take off point and runway exit points, he rest are ignored. All of my old groundnets were created like this and are still working, most of the time ;)

On another note, would it be possible to get the hold points working, this would save a lot of hassle on track back runways.

[BecOzIcan]

Hey Brett. good to see we have the same understanding of the last node rule. Do you have more info on the Hold Points, I always thought there was not code TM actually using them and they were reserved for future implementation.

[gooneybird47]

Not sure if the Hold Points were just coded into TaxiDraw for future use or if they were in FG but not implemeted, I suspect the former. I don't have my old emails from Durk so can't check it.

[Portree-Kid]

I'll check tonight. I'll be wading through the code again.

[Portree-Kid]

Nope. https://sourceforge.net/u/portree_kid/flightgear-portreekid/ci/master/tree/src/AIModel/AIFlightPlanCreate.cxx#l322

[BecOzIcan]

Reviewed and v0.0.34 and I realize I may have created confusion or misread the solution

All nodes between the thresholds needs to be considered "on runway" ie technically the "take off" box can also be used as a "landing/vacate box" for arriving aircraft and must extend the entire distance between the thresholds if we expect landing aircrafts to vacate halfway through the runway.

In v0.034, nodes placed halfway through the runway for arriving aircrafts to vacate are no longer "on runway" hence traffic manager will force arriving AI traffic to roll the the full length of the runway and exit using routes inside the TakeOff Box.

[Portree-Kid]

Ok. I'll update that after I have cleared up an issue from the trafficmanager (C++).

The aircraft lands (Leg7) until it is nearly at the park and then taxies from the nearest threshold to parking (Leg 8) That will help me come up with the correct solution.

[BecOzIcan]

Super weird never saw such a behavior. Closest I have observed is arriving aircrafts no able to find a parking spot roll to the centre of the airport and vanish but at YSSY (your screenshot), this "centre" is closer to the "P Blue Emu Domestic Parking" marking, so a bit more south