| FlightGear KSFO apt.dat.gz | X-Plane KSFO apt.dat |
|
|
external: index
internal: Image 1 | Image 2 | end
20141224: With the aim of being a 'good' FlightGear multiplayer started to look at how to set an initial startup position, that is NOT on a potentially active runway. Of course it is always possible to set a specific latitude, longitude and heading, but not so easy choosing suitable values for this.
FlightGear does have a --parkpos=name parameter, but found some 'confusion', at least in my mind, what this 'name' should be. At first I thought it would come from the old #15, or the new #1300 record in apt.dat.gz. But it seems it comes from an ICAO.groundnet.xml file. And can be a combination if name+number.
This ICAO.groundnet.xml file contains records like the following, extracted from my X:\fgsvnts\Airports\K\S\F\KSFO.groundnet.xml, a file kept uptodate by terrasync... The command line parameter to startup here would be --parkpos=D53, but in some experiments with recent git next 3.3 this did not always work, but should... and does in lots of other cases...
<Parking index="1"
type="gate"
name="D"
number="53"
lat="N37 37.101"
lon="W122 22.922"
heading="115.799"
radius="30.9576"
pushBackRoute="473"
airlineCodes="JBU,SWA,VRD" />
But first to 'visually' explore what presently exists in the latest fgdata, apt.dat.gz, for the airport KSFO, and compare that to what is in the latest 'approved' KSFO apt.dat from gateway.x-plane.com using a PolyView2D viewing tool. The extraction and xg file generation was from an aptextract.pl script, yet to be placed anywhere visible since it is a WIP, but this aptextract.txt is a recent copy, and requires lib_utils and fg_wsg84. My source of PolyView2D is part of my gitorious repository for the osm2xg project. It requires Qt4.
| FlightGear KSFO apt.dat.gz | X-Plane KSFO apt.dat |
|
|
|
Some things are obvious. While the fg taxiways are quite detail, and perhaps have some additions, it only contains about 10 parking position (blue square with white center line), compared to the xp with perhaps some 67 parking positions, and 300-400 taxi route networks (blue lines running down the center of the taxiways and runways). Click images to view at full size.
Flightgear sort to overcome this lack of parking position, and taxi route information by generating the ICAO.groundnet.xml files for quite a number of airports. Not only do these contain hopefully ALL the parking positions at an airport, but has a <TaxiWaySegments> section giving the start and end <TaxiNodes> forming a taxi route network.
|
One can see this KSFO.groundnet.xml certainly enahances the picture, and in some places has MORE taxi routes than the latest xp! But is also missing a few routes present only in the xp data, specifically the lines down the center of the runways.
It was noted during the generation of the xg file from the xml, of some 3,127 'arc' segments, half are just the reverse of another, so added some 1,359 segments, BUT skipped some 214 because either the 'begin' or 'end' index given in the <arc ... records did not exist in the 1,142 <TaxiNodes> given. Not sure why!
So FG is a mixture of 'features' generated by the terragear tools when generating scenery, and 'features' which may be added using the ICAO.groundnet.xml, at least as far as code searches, but I do not think physically dynamically drawn, like say taxiway signs.
Question: How to best combine these datasets to get all the information?
On the fg development board there has been discussion about moving all the ICAO.groundnet.xml information into apt.dat.gz. This is certainly doable, now that the current 1000 Version apt.dat specification has a new parking position record, #1300, although it does NOT include a 'radius' given in the groundnet.xml, and has records to represent the taxi route network, as shown in the above xp image.
But this increases an already rather large apt.dat.gz. It is over 100 MB uncompressed, some 2.4 million lines, 34,083 airports and even quite optimized C/C++ gzip parsing takes over a minute. Relatively recently FG only takes this amount of time on the first time run, since it uses an sqlite3 database to cache the information, and eads from there on subsequent runs.
But more than that, it then contains massive information that must be 'skipped' by the terragear scenery building tools, and likewise masses of information that must be 'skipped' by the navdata sqlite3 caching tools. And would serve to increase the already over 70 MB navdata<verions>.cache database file.
Additionally, presents quite a problem for a git update. Since it is a binary gz file, if I understand git correctly, fixing one spelling mistake causes the whole file to be replaced.
At this time, going the other way - stripping out all information NOT used in scenery building, and writing it to individual ICAO.groundnet.xml (GNX) files - makes some sense. First, some of it has already been done, so it is NOT a complete fresh start. The GNX file can contain the additional 'radius' value to set the 'size' of the parking position, making it possible to better judge what planes can park there. The GNX file need only be loaded for the initial startup ICAO.
And since this would reduce the size of apt.dat.gz, and the only a small number of airports reside in the root fgdata this would help reduce the size of root fgdata in gitorious git. And all the other GNX files would only be in google code terrascenery\data\Scenery\Airports svn, to be downloaded by terrasync.
Regretably there appears only some 90 GNX files, covering the 34,083 airports, but of course there are probably LOTS of small airports where no GNX file would be needed, although it would be nice to have them all, at least all with a ATC tower. There are just about 7,000 airports with a #14 viewpoint record.
An finally, since these are simple 'text' files svn edits and updates can be done on the usual 'line' by 'line' basis. But it would put an extra load on the terrascenery svn committere. At present I only see 4 listed members, but I am sure there would be others like myself willing to help in this effort if entrusted with commit permission.
And so the debate continues...
My aim, over time, will be to help 'improve' this parkpos, and taxi routing system, in any way I can...
As a side effect my xg file generation and viewing at an increased level can show what look like some slightly 'misplaced' parking positions even in the latest xp KSFO pack.
|
Click on image to view at full size. It certainly looks like gate F73 is a little mis-placed, as perhaps E65, E62B, D14, etc, but this would need to be checked. A Google Earth image of approximately the same locate tends to confirm...
|
But it is hard comparing apples and oranges...
EOP - 20140225: parkpos.htm
