Tower Location in FS SDK 19th ed. still blank?

[LarryJ_KMSO]

The tower location info (Lat Lon, Elev) beginning at offset 0x0D50 doesn't reflect whether this data is available for reading in FS2004. (The usual comment field column for FS2004 opposite the offset normally reading "OK" or "Not OK" is blank).

If this info is not available, how would one determine the ICAO airport code when on the ground at an airport?

Thanks,

Larry Jones

[Pete Dowson]

The tower location info (Lat Lon, Elev) beginning at offset 0x0D50 doesn't reflect whether this data is available for reading in FS2004. (The usual comment field column for FS2004 opposite the offset normally reading "OK" or "Not OK" is blank).

All that means is that I don't know whether it is working or not. Have you checked it? Once it is determined to actually work correctly (or not) I will fill in that column.

If this info is not available, how would one determine the ICAO airport code when on the ground at an airport?

I don't think the "tower location" is guaranteed to tell you that in any case! This location can be placed anywhere by the user (see the FS Map facilities), and there are some programs which deliberately move the tower location to different places so that you can get "fly-by" views of your aircraft.

I think the only way to determine the ICAO code of your airport (assuming it actually has one), would be to take the Lat/Lon of the aircraft, on the ground, and find the nearest airport listed in a suitable database of ICAO coded airports. Even then, for closely spaced airports, you could in some circumstances actually be nearer a different one when situated at far reaches.

Regards,

Pete

[LarryJ_KMSO]

All that means is that I don't know whether it is working or not. Have you checked it? Once it is determined to actually work correctly (or not) I will fill in that column.

Haven't tried reading the tower location yet. I will do so and let you know in a day or so.

Thanks,

Larry

[LarryJ_KMSO]

Good morning Pete and all,

Ref the tower Lat Lon data available at Offset 0x0D50. Here's what I found out. The values read here are close but not exact.

For example, KSEA's tower is very close to N47 27.28 where the 8 bytes at 0x0D50 shows N47 26.33. The same value N47 26.33 is read regarless of whether the 8 bytes are read from 0x0D50 as one 64 bit integer or two 32 bit integers then converted according to your directions.

I thought perhaps the location N47 26.33 was that specified in the FAA's Airport Facility Directory. But KSEA is shown in there on Lat N 47 26.94. Again close but that's not what I read from 0x0D50.

So I conclude there's information there but I don't know how to relate it to any other information. 0x0D50 certainly doesn't help one determine the airport ICAO given a lat and long.

Larry

[Pete Dowson]

Ref the tower Lat Lon data available at Offset 0x0D50. Here's what I found out. The values read here are close but not exact.

ErI don't see how that could be. What is it the location of, then, if not the tower?

Further:

For example, KSEA's tower is very close to N47 27.28 where the 8 bytes at 0x0D50 shows N47 26.33. The same value N47 26.33 is read regarless of whether the 8 bytes are read from 0x0D50 as one 64 bit integer or two 32 bit integers then converted according to your directions.

I think you are making a mistake in the computations somewhere then. Maybe you are treating the lower part as signed? An easy mistake to make.

If I go into the FS Map facility and change the KSEA tower location to N47 dead and W122 dead and 800 feet dead, this is pretty well exactly what the 0x0D50 read out then changes to. I'm only monitoring it with FSInterrogate, but it always follows whatever values you set for the Tower.

0x0D50 certainly doesn't help one determine the airport ICAO given a lat and long.

Of course it doesn't. As I said earlier, the tower position is an arbitrary viewing position, which doesn't even have to be at an airport and which can be placed anywhere by the user.

To determine the ICAO of an airport given any LAT/Lon you need to search a database and find the nearest and hope you have it right. How else do you think it would be possible in any case? Am I missing some magic computation based on arbitrary positions?

Regards,

Pete

[LarryJ_KMSO]

ErI don't see how that could be. What is it the location of, then, if not the tower?

I haven't found a value buried anywhere in FAA documentation or in MS's BGLS that refer to the Latiitude value I read at 0x05D0. Maybe I just haven't looked in the right place yet.

Maybe you are treating the lower part as signed?

So the lower 4 bytes at 0x05D0 should be read as an unsigned four byte integer and the other high four bytes beginning at 0x05D4 as a signed four byte integer? (By the way your SDK doc says the upper four begin at 0x564, a typo isn't it and in my defense, the SDK just refers to integers, you didn't say signed or unsigned)

So expressed as a formula not worrying about integer over flow etc,

TowerLat = HiSignedInt * 90/10001750 + LoUnsignedInt * 90/(10001750*65536*65536) Is this correct?

I understand what you are saying about the tower location not determing the airport. I am now thinking that the only way to be sure is to have a data base of the extents of all FS2004 airports. Then when you plop down on some runway, your coordinates are known, so you query the database to see what area area you are in and that will programaticaly yield the airport upon which you have landed. Alot of work but it could be done, I think....(':shock:')

Larry

[Pete Dowson]

So the lower 4 bytes at 0x05D0 should be read as an unsigned four byte integer and the other high four bytes beginning at 0x05D4 as a signed four byte integer?

Yes, of course, since the lower part are merely the lower 32-bits of the complete 64-bit signed integer. You can't have two sign bits in one number.

(By the way your SDK doc says the upper four begin at 0x564, a typo isn't it

Ah, copy and paste error, not typo exactly. Thanks. I'll fix it.

and in my defense, the SDK just refers to integers, you didn't say signed or unsigned)

Ah, the fuller explanation is in the 0560 part. Sorry. It seems i'll have to reproduce the whole text in every place the same notation is used. :( In 0560 the differentiation between "int" and "unsigned int" is emphasised by emboldening in the original:

"To do, copy the high part (the 32-bit int at 0564) to one double and the low part (the 32-bit unsigned int at 0560) to another (say dLo). Remember that the low part is only part of a bigger number, so doesn’t have a sign of its own."

So expressed as a formula not worrying about integer over flow etc,

TowerLat = HiSignedInt * 90/10001750 + LoUnsignedInt * 90/(10001750*65536*65536) Is this correct?

Probably, though it would need tidying to work as a program of any sort. Since the whole thing is in units where 90 degrees is represented by 10001750, it is easier to understand if you consider the joining of the two parts as merely making one number (65536*65536 is just my easier-to-remember way of referring to the 32-bit capacity of the lower value -- can you call what 2^32 is in decimal offhand? :) ), and then the scaling is multiplying by 90 and dividing by 10001750.

This system of representing things in FS dates back many many years by the way. FSUIPC just gives you what FS gives it.

I am now thinking that the only way to be sure is to have a data base of the extents of all FS2004 airports. Then when you plop down on some runway, your coordinates are known, so you query the database to see what area area you are in and that will programaticaly yield the airport upon which you have landed. Alot of work but it could be done

Yes, but largely unnecessary. Unless you are at the very far reaches of some sprawling airports which are close to some small field, just using your Lat Lon on a database of airports will do -- just find the nearest. There won't often be ambiguity. I think airport databases are easy enough to come by -- some of the AI traffic utilities make them I think, for instance.

Regards,

Pete

[Pete Dowson]

By the way your SDK doc says the upper four begin at 0x564, a typo isn't it and in my defense, the SDK just refers to integers, you didn't say signed or unsigned ...

In the next version I'm replacing all three entries, 0D50, 0D58 and 0D64 with just the one, so:

0D50 24

The Tower Latitude (8 bytes), Longitude (8 bytes) and Altitude (8 bytes) in the same format as 0560–0577 above.

Ok Ok

like I've already done with tne viewpoint location at 05B0. Then I've only got one explanation to keep expanding! :D

Sorry if it was confusing for you. The original source for all this merely said "FS units" by the way, you had to forage in quite complex ways to work out what they were. At least I think my documentation is a bit better.

Regards,

Pete

[LarryJ_KMSO]

Thanks for your detailed explanations which !!! YES!!! I do understand.

And thanks again for being there and being so helpful. Your SDK has been the excuse for two programming projects so far with a third just starting. Great fun. You're the best, Pete! Keep it up as long as you can.

Larry