pellelil Posted January 19, 2020 Report Share Posted January 19, 2020 Hi Pete/John There seams to be a bug in MkRwy version 4891 regarding airport elevation, that was not there in version 484. For my software (Flightplan Visualiser) I use MkRwy to scan installed scenery to obtain info regarding the airports, and I just had an issue with this software which I though was a bug in my own software, but it turned out to be an apport with an elevation greater than 60000 ft. I then put into some code to test how many airports that hat an elevation that was more than 1000 ft appart from what I think the elevation should be (based on some other airport data I have in my software). It turned out that the elevation was off at most airports: 20:24:21.177|1|INFO|Elevation correction: UTSL, changed from 130899 to 1309 20:24:21.193|1|INFO|Elevation correction: UTSS, changed from 222401 to 2225 20:24:21.193|1|INFO|Elevation correction: UTST, changed from 102699 to 1028 20:24:21.193|1|INFO|Elevation correction: UTTT, changed from 141399 to 1417 20:24:21.193|1|INFO|Elevation correction: UUBP, changed from 63001 to 666 20:24:21.193|1|INFO|Elevation correction: UUDD, changed from 53499 to 594 20:24:21.210|1|INFO|Elevation correction: UUDL, changed from 30499 to 305 20:24:21.210|1|INFO|Elevation correction: UUEE, changed from 62992 to 630 20:24:21.210|1|INFO|Elevation correction: UUEM, changed from 46899 to 469 20:24:21.210|1|INFO|Elevation correction: UUOB, changed from 73501 to 735 The 1st value is the elevation as detected by MkRwy and the 2nd is the from the other data-source I have. Installing MkRwy 4.84 in stead, this problem (with wrong elevation values) disapear. Pelle Link to comment Share on other sites More sharing options...
pellelil Posted January 19, 2020 Author Report Share Posted January 19, 2020 Ahhhh I see. Altitude was changed from an integer value to a float, which my software did not detect. Version 484 write it as: <Altitude>630</Altitude> Version 4891 write it as: <Altitude>629.92</Altitude> Link to comment Share on other sites More sharing options...
Pete Dowson Posted January 19, 2020 Report Share Posted January 19, 2020 2 hours ago, pellelil said: Altitude was changed from an integer value to a float, which my software did not detect. Version 484 write it as: <Altitude>630</Altitude> Version 4891 write it as: <Altitude>629.92</Altitude> Yes, but even if you read it as an integer (eg conversion via the "atoi" library function) then you'd at most only be 1 foot out. It was changed to allow the automatic correction of the altitude 'bugs' introduced by the P3D4.5 HF2 to handle altitude changes in layers differently. It was requested for FSAeroData. Sorry this had an adverse affect on your software! 😞 It didn't appear to do any harm as it was natuarally assumed that programs would either convert it using XML tools (which should be immune to the change, no?), or would at worst treat it as an integer up to the '.' which would terminate a loop looking for decimal digits. Of course, I suppose that '.' might be treated as a thousands separate by some non UK/US ways of handling it. But looking at your results was that '.' simply discarded? Pete P.S. From the Release Notes in the Download Links subforum: -- Version 4.891 provides altitudes accurate to 2 decimal places in the Runways.xml file (only). Link to comment Share on other sites More sharing options...
pellelil Posted January 20, 2020 Author Report Share Posted January 20, 2020 Pete, I probably have myself to blame as I use a non-standard method to convert what I read, so my software read "629.92" as "62992" (as it removes all non-number chars before converting). Anyway I changed the software to expect a floating-point now 🙂 Pelle 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