A NavDB web service
| This article is a stub. You can help the wiki by expanding it. |
Challenges
there's no terminal at Kai-tek (realistic!) and the generic OSM skyscapers would be great, as well as the chequerboard and lead-in lights. (Really we should make these pieces conditional on the simulator date, since Kai-Tek is long closed - we do that for some other time-sensitivie landmarks).[1]
This use scenario highlights a fundamental problem with our scenery approach, in dealing with historical periods. We just have no good way to have most of the nav data be current, but some portions reflect the world as it was in 1960 or 1980. I would prefer we maintained some global historical data sets of nav data, but in principle this would also mean maintaining historical scenery and airports, and selecting / de-selecting models based on data ranges. (So buildings appear based on their construction / demolition date). Obviously that’s a colossal amount of work which is not going to happen without effort. [2]
Background
|
|
|
we'll need the capability to to have two clients access the NavDB concurrently - I've hit lots of errors trying to do this |
|
A user once asked in the forums whether FG wouldsupport navaids not only from the nav.dat.gz file, but from files in custom sceneries. For example, in ULLI airport there is a problem with glideslope and NDB at the O0outer markers and there are missing NDBs at middle markers. A user made a correct version of nav.dat.gz, but it worked only on his computer. He could distribute his scenery with the fixed nav.dat.gz, but if another player had made his own modifications in his own nav.dat, they would conflict. It would be possibls to write instructions how to find bad data and replace it with good data, but not every player wants to do such things, especially, if he has played MSFS earlier. That the main problem.[3]
We have a workflow for scene-models that works well - people submit data (models), a central server / DB / etc collates them, and periodically new versions are available to everyone (terrasync, whether online / offline / manual). The exact same flow can work for nav data, ideally in the same place. We can augment Robin’s data (or not), maintain versions in sync with scenery (indeed, James Turner would move the data into the terrasync file tree next to Airports/ and Models/), etc.[4]
Objective
At least for the US, there's a ton of data freely available that can be extracted from such charts procedurally using a bit of scripting and OCR or regex. The corresponding data could be put into a database and updated regularly, according to the AIRAC cycle. But something like that should really be a central web service - in FG, we now have the means to easily download data via HTTP, and make web service requests. In other words, we could populate some kind of central navdb with our existing data, update the whole thing with the kind of data provided by the scripted discussed at A project to create a source of free geo-referenced instrume post on the forum 
.
At that point, we would have a web service that could run a cron job to regularly update the whole thing - maybe in combination with some kind of wiki-like front-end to allow contributors to update/edit and maintain entries for different countries and navaids, as well as procedures.
The navdb would then be md5-hashed and fetched on demand, so that the navcache can be updated/rebuilt accordingly. [5]
EFB
For a complex EFB, it would be possible to create 100% of the charts procedurally, including charts for TPs (terminal procedures like SIDs/DPs, STARs and IAPs) - the main issue is lack of data. And even if we get our hands on a relatively recent AIRAC cycle, the FG side of things (navdb) will not match that data. And in FG, we don't currently have the corresponding TP data. Converting/rendering existing charts (even PDFs from airnav.com) should be straightforward, but the FG world would use a different set of navaids and FIXES. So, we'd be better off looking at how X-Plane handles this challenge, given that they also used to use DAFIF(T) originally.
In general, developers would probably favor procedural creation if we could get the data - and short of that, I'd use the approach discussed a while ago: A project to create a source of free geo-referenced instrume post on the forum
Such charts would be centrally created, along with VRT (XML) files for geo-referencing them, so that the corresponding charts could be requested at run-time and downloaded on demand (or cached). We could probably use a simple form of OCR to extract navaid info from such charts to obtain relevant navaids for the given sector - it's just our navdb design that is kind of inflexible at the moment, but we could certain enrich/augment existing data using such updated data for navaids and fixes (or procedures).[6]
Status
http://navdata.fgx.ch/[dead link]
The NavData project takes the latest xplane data, imports it to a postgis database spatially ready for querying on demand. It is intended as a "permanent" feed moving foward and making the latest xplane data available and updated for all, whether for caching local or online live. The data returned is formatted in a pratical way with a lot of the calculations already done, such as the middle of an airport, runway center point, orientation and displaced threshold etc. Also measures are returned in different units such as evelation both in metres and feet to make life easier for both calculation and presentation for end user application. [7]
Developer's Plans
We quote ac001: 'I'm the developer behind navdata.fgx.c and thanks to Hooray for alerting me as i dont follow the forums much...
So What I would want is to publich the xplane data.
But also have a way to "submit corrections", and maybe have a voting system of "yes this is correct".....
Problem is to create and automated way to send this upstream to Robin the xplane maintainer.. but am well into this stuff
Problem with navdata at the moment is I need some users to check the api and make it "usable" moving forward...' [8]
Coordinating with XPlane
Coordinating this with Robin Peel would be awesome, because of the sizable XP community, i.e. we could truly benefit here by leveraging our two communities to help update such data. At some point, someone even came up with a script to extract such stuff procedurally from airnav/TPP charts. This is something that me worthwhile to explore again. API-wise, it would be a good idea to provide a mandatory version attribute, so that you can safely upgrade things later on, without features breaking. [9]
Also see: http://sourceforge.net/p/flightgear/mai ... sg32324567
Robin is already working on improving the submission side (of apt.dat at least). See http://developer.x-plane.com/2013/12/ai ... -airports/ [10]
If you know:
- someone who is willing to develop, contruct and maitain the full airport diagrams database + its implementation;
- a solution better than the formats used in XPlane;
- someone who has the time to rebuild the whole toolchain to analyse this new format;
- build a nice and crossplatform tool we can use to build airports;
- with a GPL license.
Then, we'd willing to hear about him - or her. [11]
Advantages of staying with XPlane
There are so many advantages when reusing the X-Plane data and their format, they have a HUGE community of contributors - which FG simply doesn't have.
On the other hand, some web-based frontend to allow people to easily contribute and maintain airport/navdb data, would be great to have. Something pretty much like a "GIS Wiki", possibly based on PSQL or even git - so that people could go to a website, open an airport/navaid and file merge requests, review entries and help maintain all the data there would be useful.
The new scenemodels submission process is actually a very good example here.
Something like this could be very useful, not just for airports (runways, taxiways, aprons etc), but also for navaids and terminal procedures (SIDs/STARs and IAPs).
And I guess we could even get the X-Plane community to contribute to something like this. The whole work flow could be moved to a website, so that it would be easier contribute.
Using git as the backend (i.e. plain text files) would have the advantage, that we'd also get a revision history automatically.[12]
We need to learn the Open Street Map lesson here.
References
References
|