Nosewheel Coordinate Position

[Portree-Kid]

The user wants to edit/enter the nosewheel position.

[BecOzIcan]

Background/Context

• XML format of groundnet known

• INS (NoseWheel) Lat Lon of Parking Stands available in published eAIPs

• INS Data can be reworked in excel to meet the expected XML format (as Nodes) and then opened up in Taxidraw, forming a cloud of nosewheels points. It is then the normal process to Create ParkPos and place them so that the nosewheel aligns with the reference node uploaded previously.

• The process cannot be replicated in FGA as the program does not handled unconnected nodes (orphans)

• Agreement made that on ingest (yet to be developed) any such 'orphan' node found in the ingested xml will be converted to a Parking position

Issue:

• FG Expects the Lat / Lon of a parking position to be the model center of rotation (main gear) and not the nosewheel so Parkpos created from FGA ingest process will be misplaced AND (visually) the reference point will be lost

Options/solutions :

• Clean but missing data : Ingested Orphans are converted into Parkpos but the orphan lat/lon is used to place the parkpos nosewheel. Cannot be achieved without knowing the parkpos heading
• Clean but architecture blockage : Ingested orphans are converted to unlinked nodes
• Clean and Feasible : Dedicated ingest process (Separate from ingesting an existing groudnet) does NOT add the INS orphans to the groudnet xml but treat them as an extra background layer, similar to OSM or APT DAT. User can see on the map where nosewheels are in eAIP and align parkos accordingly.
• Dirty : Ingested orphans are converted to a dedicated route linking them all together. Use only as visual guideline : User needs to delete the nodes/route once final parkpos in place

I would vote for Clean and Feasible

[Portree-Kid]

This is a mock for clarification what I'm talking about. I want a way to enter the heading indirectly via two points. These would be center & nosewheel naturally. That way you could use a license free sat data to grab points to get your heading. The other use case is of course if you just have pdf with nosewheel & heading.

[BecOzIcan]

You could get away with a simple solution (WED Style) where you have a 'lock' tick box next to nosewheel Lat/Lon If Active (locked) then

1. PP Centre Lat/Lon greyed out (calculated only)
2. User can still vary heading but then the Parkpos pivot around the nose wheel (and PP Centre LatLon is recomputed)

[Portree-Kid]

Good idea. This way the flow is clear.

[BecOzIcan]

So I get that right (Looking forward to putting the user manual / documentation together ... not)

1. The default (current) is nose wheel highlighted in blue because I set my PP lat lon and my heading and you calculate the nosewheel position
2. Center is highlighted > scenario I described before ie I can set NW and heading
3. Shownon your screenshot Is your previous scenario where I give you two points (center and NW) and you sort out the heading.

BEWARE the user should be able to vary the radii which will impact calculations: I set my nose wheel then align my heading then realize the PP does not fit so I want to reduce the size from D to C while my nose wheel and heading do not change (but my PP does)

The UI is spot on ! I was about to send a message about a toggle but you beat me to it

[Portree-Kid]

Tricky. Maybe I disable the size together with the heading and the size recalcs together with the heading. Use case is you are tracing from a map.

1. You enter Nose Wheel pos from map
2. You enter center from map
3. You switch to Nose Wheel or Center and adjust the size.

alternative would be that in Heading mode the center is always recalculated based on size.

[BecOzIcan]

Correct. In "Heading Locked" the user won't even be able to pick any radii (calculated from the pair of lat/lon). Not only this will create issues downstream (radii will fail validation 100% of time) but I also can't figure out a clear benefit to balance that.

In the other two scenarios a single lat/lon is entered by user and the radii is simply one of the factors in the calculation so not blockage at all. These 2 align totally with the current process and the data available whilst still improving the user comfort so I would say limit the toggle to nose and centre for the time being and let s reassess.

[Portree-Kid]

Yes the business of ratcheting of the radius would not be clear. I'll move my use-case of wanting to enter heading via a point on the heading line into another place. Too confusing.

[Portree-Kid]

Fixed in 0.0.21