fsaerodata Posted November 7, 2019 Report Share Posted November 7, 2019 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 Link to comment Share on other sites More sharing options...
Pete Dowson Posted November 7, 2019 Report Share Posted November 7, 2019 1 hour ago, fsaerodata said: 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. Hmm ... and you automate this using MakeRwys files? Otherwise, if it only the information you need to specific airports surely something like ADE would do? I'll take a look at the code. If it is a relatively trivial change i'll do it. But I hope the resulting files are acceptable to all existing users. I'll need to add a warning just in case. i don't want it as an option. BTW, whilst I have your attention, I did subscribe to FSAERODATA, but somehow I could never get updates. For a while you supplied me with a link by email, but that service dried up, so I have been using Herve Sors updates instead. Is the FSAERODATA service now fixed? Pete Link to comment Share on other sites More sharing options...
Pete Dowson Posted November 7, 2019 Report Share Posted November 7, 2019 2 hours ago, fsaerodata said: 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. Have you got the right airport ID there? My charts say CYPZ runways are at 2343 feet not 2351. Checking in MakeRwys I get 2342 feet. That's with default CYPZ. Looking into the raw data it would be 2342.39 feet. Please confirm so I can check. It does look relatively easy to make the change. Pete Link to comment Share on other sites More sharing options...
fsaerodata Posted November 7, 2019 Author Report Share Posted November 7, 2019 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 Link to comment Share on other sites More sharing options...
Pete Dowson Posted November 7, 2019 Report Share Posted November 7, 2019 7 minutes ago, fsaerodata said: 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". All the runways files have runway altitude, not necessarily airport altitude. In the case of CYPZ they are all the same. so i can check my changes, do you know of a default airport where the runways have a different altitude to the airport? 9 minutes ago, fsaerodata said: 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). Okay. that makes more sense. 11 minutes ago, fsaerodata said: 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. Thank you! Of course it has probably expired by now in any case. 😞 Pete Link to comment Share on other sites More sharing options...
Pete Dowson Posted November 8, 2019 Report Share Posted November 8, 2019 19 hours ago, Pete Dowson said: It does look relatively easy to make the change. Try this test version 4.8.9. Pete MakeRwys489_TEST.zip Link to comment Share on other sites More sharing options...
fsaerodata Posted November 8, 2019 Author Report Share Posted November 8, 2019 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 Link to comment Share on other sites More sharing options...
Pete Dowson Posted November 8, 2019 Report Share Posted November 8, 2019 2 hours ago, fsaerodata said: 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. I already said the default for CYPZ I was getting was 2342.39. When it was an integer it was 2342. Why didn't you reply before to say you thought 2432.39 was wrong? It would have saved time! To 5 decimal places there are 3.28084 feet to a metre. Because no one has EVER need anything so accurate for feet I use 3.28. Which in this case gives the value you are getting. The difference between 3.28084 and 3.28 is a mere 0.03% I thought you wanted just a more accurate value. Are you saying you really need the number read from the BGL? Even the 3.28084 is probably an approximation, I can re-do the test build using 3.28084 is this is really so desperate, but i'd like to know why beforehand please! Pete Link to comment Share on other sites More sharing options...
fsaerodata Posted November 8, 2019 Author Report Share Posted November 8, 2019 (edited) 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, Edited November 8, 2019 by fsaerodata Link to comment Share on other sites More sharing options...
Pete Dowson Posted November 8, 2019 Report Share Posted November 8, 2019 37 minutes ago, fsaerodata said: Nevertheless, if you consider that the change may bring incompatibilities, execution times, additional complexity, or development time, please disregard my request. Well, that depends. Do you need your users to run MakeRunways, or is it only used in house to generate your data? I am just a little concerned that programs processing MakeRunways files using their own scanning methods may stumble over the unexprected "." decimal point in the Altitude. I don't think that would be a problem with XML files, so if you only need it there I can restrict the change to that file. Would that be okay? 37 minutes ago, fsaerodata said: 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. Do you think the 0.03% difference in the version I already offered could cause such a phenomena? I think the cockpit altitude above the ground is much less accurately computed than that, and even the Radar Altitude isn't actually computed from the underside of the tyres. Nevertheless, if you only need it in RUNWAYS.XML i will make the computation accurate, using 3.28084 instead of 3.28, and provide it to 2 decimal places in that file only. That should upset nothing and allow me to make it a general release. The only result in the other files (r4 and r5.csv) would be that the .99 will round the integer result to 2343 instead of the previous 2342. Let me know. I can do that quite quickly, then, if it is suitable, make a Release. ============================= BTW will I be able to get Aerodata from your website? Please email me (petedowson@btconnect.com) my credentials so that I may start using it again. After the download problems i kept getting I went over to the Herve Sors free ones, but they are a bit more of a hassle to install. I've forgotten or lost your data. Pete Link to comment Share on other sites More sharing options...
fsaerodata Posted November 9, 2019 Author Report Share Posted November 9, 2019 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 Link to comment Share on other sites More sharing options...
Pete Dowson Posted November 9, 2019 Report Share Posted November 9, 2019 2 hours ago, fsaerodata said: 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. Okay, I understand now. Please test this one. If it is okay I'll release it properly, so let me know. You can either supply it with your product (with the instructions of course) or just tell your users to get it. 2 hours ago, fsaerodata said: I'm sending an email to you with the details, Got it! Thank you! Pete MakeRwys4891_TEST.zip Link to comment Share on other sites More sharing options...
fsaerodata Posted November 10, 2019 Author Report Share Posted November 10, 2019 Hi, this version is OK. Thanks for your excellent support! Jose L./fsAerodata Link to comment Share on other sites More sharing options...
Pete Dowson Posted November 10, 2019 Report Share Posted November 10, 2019 40 minutes ago, fsaerodata said: this version is OK. Right. I'll mske the public release tomorrow. Pete Link to comment Share on other sites More sharing options...
jabloomf1230 Posted November 12, 2019 Report Share Posted November 12, 2019 Pete, A thank you from me also, as an fsaerodata user. Jay Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now