A NavDB web service

From FlightGear wiki
Revision as of 07:14, 21 May 2015 by Red Leader (talk | contribs) ({{dead link}})
Jump to navigation Jump to search
This article is a stub. You can help the wiki by expanding it.
WIP.png Work in progress
This article or section will be worked on in the upcoming hours or days.
See history for the latest developments.

Background

Cquote1.png Will FG support navaids not only from nav.dat.gz file, but from some files in custom sceneries?

For example, in ULLI airport there is problem with glideslope and NDB at Outer markers and there are missing NDB at Middle markers. I made right version of nav.dat.gz, but it works only on my computer. I can distribute my scenery with fixed nav.dat.gz, but if player have own modifications in own nav.dat, they will conflict. I can write instruction how to find bad data and replace it to right, but not every player wants to do some actions, especially, if he played MSFS earlier. That why I'm asking it.


— Soitanen (Sun Jan 06). Re: Why does Flightgear use X-Plane airport data?.
(powered by Instant-Cquotes)
Cquote2.png

Objective

Cquote1.png 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 Subject: A project to create a source of free geo-referenced instrume.


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.


— Hooray (Sun Jun 22). Re: 777 EFB: initial feedback.
(powered by Instant-Cquotes)
Cquote2.png
Cquote1.png like you said, we can 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, I'd probably favor procedural creation if we can get the data - and short of that, I'd use the approach discussed a while ago: Subject: A project to create a source of free geo-referenced instrume


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)


— Hooray (Sun Jun 22). Re: 777 EFB: initial feedback.
(powered by Instant-Cquotes)
Cquote2.png

Status

Cquote1.png http://navdata.fgx.ch/[dead link]
Cquote1.png 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.
Cquote2.png

Cquote2.png
Cquote1.png I'm the developer behind navdata.fgx.ch

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...


Cquote2.png
Cquote1.png 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 I'd just suggest to provide a mandatory version attribute, so that you can safely upgrade things later on, without features breaking.

Also see: http://sourceforge.net/p/flightgear/mai ... sg32324567


Cquote2.png
Cquote1.png Robin's already working on improving the submission side (of apt.dat at least). See http://developer.x-plane.com/2013/12/ai ... -airports/
Cquote2.png

A NavDB wiki ?

Cquote1.png 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, I'm willing to hear about him - or her.

I don't really understand what you mean by "better solution" and "more freedom" regarding the airport data format.


Cquote2.png
Cquote1.png 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 in my opinion:
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.

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.


Cquote2.png
Cquote1.png I totally agree with that. The OpenStreetMap lesson has to be learned here
— robitabu (Fri Mar 16). Re: Why does Flightgear use X-Plane airport data?.
(powered by Instant-Cquotes)
Cquote2.png