Just to be clear about it, while the screen shot I posted dates back to around ~2012, it did definitely parse/process and create the corresponding Canvas taxiway chart in Nasal space - that was one of the reasons why it was so extremely slow, and disabled at the time - in fact, we used KNUQ as the test case to optimize the Canvas system.
So, while I haven't been following FlightGear core development recently, I do think that the underlying infrastructure still is in place - and James' comments also indicate just that (I believe he wrote most of the original FGPositioned APIs, which Tom susequently ported to use CppBind instead).
That being said, at the time, we discontinued the taxiway layer due to its runtime cost (it being processed in Nasal space), and instead suggested to expose the Canvas element base class (sc::Element) to scripting space, so that new layers (Canvas elements) could be directly prototyped in scripting space using property rules. I don't know if any of that materialized or not, but Stuart seems to have used the Canvas system to create rather sophisticated avionics (see the FG1000).
And given your use-case here, the underlying APIs would obviously remain useful regardless of any specific application.
In fact, at some point, a handful of core devs were contemplating to make shapefiles directly accessible to Nasal/Canvas space.
Again, if in doubt, check back with Zakalawe above, since he wrote most of the original navdb related code.
In the meantime, you could also use the Nasal console to run a MapStructure dialog with taxiways enabled, and open KNUQ:
https://wiki.flightgear.org/Canvas_Snip ... o_a_CanvasEDIT: I just checked $FG_ROOT/gui/dialogs/airports.xml doing just that, and here's what I am getting (without having any terrasync/scenery installed):
(And I am really sure that this stuff is processed in scripting space, because I used to code up that stuff back then)