5 comments on “apt.dat 1050 Proposed Format Changes Posted

  1. I believe this is an good idea if I understood it correctly. But shouldn’t gate size be determined by aircraft weight, fuselage length, wingspan, height along with wheel base?

    When I start XP I would love to be able to search IACO or Airport Name, IATA does not factor that much to me, but I guess we use different approaches when searching. Let’s say I want to start at Oslo Airport, I would then search ENGM, if that’s not available or wrong, I would try Gardermoen (shorten nick) even though the airport is officially called Oslo Airport Gardermoen and the IATA name is OSL .

    1302 icao_id ENGM
    1302 faa_id OSL
    1302 iata_id OSL
    1302 name_id GARDERMOEN <— This would be great to have added.

    Question, would a redesign of these apt.dat codes make if possible to include gate selection in the gui based upon a set of new identifiers Ben?

  2. 10.50 ? This weekend ? 🙂 Maybe… I noticed some new city textures. They are only noticeable from the distance and or really high up. Looks good ! When did this get added ?

  3. Hi,

    Out of curiosity, I always thought that holding these kind of information/data is best managed by an embedded database, like sqlite. I think it was used in WED.
    For apt data, wouldn’t it be easier to maintain and enhance this kind of data in one big table that mimics the apt.dat file.
    The benefits:
    1. It will still retain the openness for 3rd party or end users to modify, although they will need a client to do that (which I do not find a bad option).
    2. It should allow to update the information on the fly.

    Just a thought

    1. We considered that. But meta-data on the apt.dat is the only way for third party scenery added in later outside the gateway ecosystem to also have meta-data. And the current method of crowd-sourced updating is based on apt.dat files, not a CRUD interface to a database.

Comments are closed.