MkRwy regarding elevation

[pellelil]

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

 

 

 

[pellelil]

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>

[Pete Dowson]

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).

 

[pellelil]

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