A small note:I am changing OR to reduce the impact of a server availability of our shapefile download server. This server is hosted by someone else, who does a lot to keep it up and running. In the past there have been issues when hardware failed. But after all, this server is maintained in spare time and OR should not rely too much on it.

As the server stable for years, I did not implement anything to handle fail situations. I am changing this now: Download issues will be displayed without checking logfiles and you will have the chance to run OpenRadar without the scenery download. This emergency mode cannot display landmass, lakes, rivers and so on, but I can produce all details, that have another data source: All navaids, airports and even the runways can be displayed. Biggest flaw is the absence of the taxiways. I will check if I can do something for that too...

To summarize, in emergency situations, OR can run without the downloaded shapefiles. It is not nice, but ATCing works...Wolfram

Hello from across the other forum As the ATC-pie dev, I am interested in the technical side of this discussion, which I feel might be coming and interesting for both programs. Should it be a nuisance for anyone here, a dev forum can be followed up into.

WW: Did you mean taxiway *names* or only shapes? For the record, ATC-pie has never relied on external servers for airport data. So it has never showed lakes or landmass, but it does have tarmac, runway and taxiway shapes, never blocking at startup. I remember it taking me a little while to decipher their rather underspecified and less-documented description, so I'll be happy to assist if you need anything. Though I suspect the shape server might have a similar encoding...

Hooray: I had neither explored nor even heard of "FGPositioned APIs". I feel like I have not captured the full extent of what you are proposing, but it looks like it includes ground nets and could include TWY names... Is there any additional source for those besides the Xplane data? Sourcing only from the Xplane data myself, ground nets are absent and TWY names were almost invariably messy so I ended up turning them off because they were useless; only tarmac shapes looked good... after some work. Would you have a solution for properly named taxiways?

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:

this here was written out of sync before the last post of Hooray:In emergency mode I take the runway information from the xplane data available in flightgear (apt.dat copied to OR installation). Until now I have ignored the other information there. Using the taxiway layout data there in OR is the next step I plan to do. I have tried to use the flightgear ground network data in OR, but the coverage was not good enough.

Historical: OR was started as a radar map based on the shapefiles, data files that deliver coastlines, rivers and cities... As I took it over, there was the map only and few reason to change everything. I haven't used the xplane data in the past, because there have been inconsistencies between scenery shapefiles and xplane data. If I remember it correctly, also the coverage of the shapefiles was a lot better than our xplane data.Currently, I don't plan to use scenery data in OR, because I don't want to implement another svn client.

My next steps are: I will keep the shapefiles in OR, as it is the heart of OR. Additional, I will improve the "emergency mode". If I can get it good enough, I will offer it as an alternative to the shapefiles. Advantages are quicker airport setup and quicker startup phase.If possible, I don't want a direct dependency to flightgear, I don't want to force the user to have a specific flightgear installation on his harddisk, nor force him to download a specific part of the scenery for OR. The current separation between the tools was very good: Both sides could make progress and we had only very few side effects onto each other.

Hooray: Your proposal has many good arguments. But for all of us, this seems to be something new, a development target. The solution I have described here, is a solution for the short and mid-term... Once I have this in place, OR runs again, and we have time to implement it...