fsaerodata

Hi, this version is OK. Thanks for your excellent support! Jose L./fsAerodata

Hello, I agree; the format 'runways.xml' should be fine. The user will run MakeRwys on their machine, generate the report, and run a fsAerodata script that reads the correct elevations and update them on a fsAerodata bgl file. It's not so important the error in %, but it can make a difference in absolute terms. In the previous example, 0.6Ft is relevant. See below one example with the fsAerodata bgl file updated with the altitude used by the 3rd party scenery, and the second one with a slightly different value; the runway and other airport elements sink under the airport ground. fsAerodata with elevation matching 3rd party airport (Orbx CYPZ shown here): 2351.99F - OK. fsAerodata with slight deviation on elevation value vs airport's value: 2351.39F - NOK. I'm sending an email to you with the details, Thanks

Hello, I initially thought that value was the elevation at the runway, sorry about that. Nevertheless, if you consider that the change may bring incompatibilities, execution times, additional complexity, or development time, please disregard my request. Background of the change request: the latest Prepar3D v4.5 HotFix2 brings modifications on how the scenery altitudes are read. Starting with v4.5 HF2, the airport altitude is taken from the scenery with the highest priority. Since we use some SDK extensions to override and update some aeronautical data, the altitude value stored on our bgl file, must be the same as the 3rd party scenery; otherwise, there may be elevation conflicts (aeroplane sinks or floats over the runway). That's the reason to have elevation values with 2 digits. Regards Jose L/fsAerodata,

Hi, thanks for the quick reply I think there is an error when reading the raw value on bgl file. For example, on stock CYPZ I get following values: MakeRwys: 2342.39F. fsAerodata or ADE: 2342.999F; equivalent to 714146 (Int32) / 1000 / 0.3048 Regards, Jose L./fsAerodata

Sorry, it's the airports altitude, what I'm interested on; not the runway value; my mistake. Then, the correct file where airport elevation is available is "runways.xml". Based on that, CYPZ elevation is 2343F on runways.xml for the default airport. The example I mentioned on my first post refers to CYPZ from Orbx Global, which shows 2351F on MakeRwys (the raw value on ADE is 2351.98F). I'll check your subscription and reactivate it; the download server was improved 1 year ago, and there are no reports of broken downloads anymore. Thanks, Jose L. /fsAerodata

Hi, This is a request to update the precision of elevation data collected by MakeRwys, adding two decimal digits and get a higher accuracy; currently, the values are of type integer. The idea behind is to override some aeronautical data within 3rd party airport addons (specifically airport comms and approaches) using some of the SDK extensions available on Prepar3D; After the new Prepar3D HotFix2, this data can be updated only when the exact elevation value of the airport is used. The tests were done using the format used on rc4.csv For example, CYPZ elevation of a commercial airport is 2351.98F; CYPZ reported by MakeRwys is 2351F instead. Thanks and Regards Jose L. /fsAerodata