just briefly: my suggestion would be to use an SQLite browser/editor and go to $FG_HOME to open the navcache there (see the wiki link above), you can then inspect the whole navcache - what you find in it is basically a mix up different sources (including Xplane data) - and most of it is available at run-time via FGPositioned APIs and their corresponding Nasal equivalents.
So given that we are talking about Python and Java here, you could either turn the FGPositioned C++ stuff into a reusable library for use by OpenRadar/ATC-Pie, or simply read the navcache directly. With the latter having the disadvantage that people need to have fgfs installed locally.
Otherwise, you could also extract the relevant data from the navcache and ship that with both ATC clients.
However, please see the wiki: the main guy behind the navcache is Zakalawe, and he would prefer if people didn't access/process the navcache directly but only use the FG-specific APIs.
Personally, I think that this is a novel use-case and I would probably simply read/ship the cache directly and move on.
That said, this opens up the question if the navcache should really be an integrated component, or if it might not be better to turn it into a standalone library/program that could be used by multiple processes, regardless of fgfs having to be installed/running, i.e. some form of true database.
Overall that would seem like the best solution to me, because the navcache is a feature that has severely crippled the fg experience for many new users, so that it would make sense to move this to a dedicated/standalone component and use it like a conventional database.
There are so many similar programs that need to access this very data, that it is simply inefficient to copy/paste code and adapt that, and in a MP/VA or ATC scenario, you would also want to ensure that all "players" (clients) are using the same underlying database, which is why I believe that it would be better to have a true server/client model, where fgfs would only connect to a locally running database - which in the fg case, could even be running in a backgound thread (e.g. via HLA).
It is already unfortunate that the navcache is not a true subsystem and that its internal data dependencies are not formalized, so the whole thing could just as well be moved to simgear, so that OpenRadar/ATC-Pie can more easily reuse it (either as a binary library or via standalone program/networking (IPC)).
Note that this is not a new discussion/idea, for some background info refer to the atlas project on sourceforge:
http://sourceforge.net/p/atlas/feature-requests/10/http://sourceforge.net/p/atlas/feature-requests/16/I don't know why this got filed at the atlas tracker, whereas it is related to the fg/sg projects - but probably that is because at that time, fg was not using any issue tracker at all
A more recent discussuion we've had is summarized at:
http://wiki.flightgear.org/A_NavDB_Web_ServiceIf in doubt, get in touch with Zakalawe on the devel list, the navcache is his baby after all ...