Airspace information

[taguilo]

...
That's a gauge I created to help me get deeper into the detail of the CustomDraw Map capabilities of the gps module. I am in the process of updating the GPS Guidebook and it will include discussion of all of the Map and Rose variables. The map gauge has had a rather meandering development and is still work-in-progress. The screenshot is of version FSX-83.

Bob, your gauge is really impressive. And I guess entirely coded in XML -except for the supporting modules-A great work!

Tom

 

[eric_marciano]

I think I did it !!!

Look at the following screens, I intentionally displayed the GPS airports and MY aiport objects. As you can see, they are displayed at the same position. It means I finally have the same projection as the GPS and I can now use the map as a background for my moving map.
The first image is at a "normal" location (LFBO, Toulouse, France) and the second image is made at high latitudes, in the north of Norway (ENHK). Both images show good results

Now I have to test it with FSX...

Eric

 

[TKelley58]

Airspace puzzle solved

i too have a need to resolve an airspace issue.
we are trying to update an airport in the US that has changed it's airspace.
hard to sort out this puzzle....

 

[eric_marciano]

i too have a need to resolve an airspace issue.
we are trying to update an airport in the US that has changed it's airspace.
hard to sort out this puzzle....

Even if this discussion covered much more topics than initially expected, my initial question was about the ability to READ airspace information. Even if it is not really easy, solutions exist.
What you ask is the ability to MODIFY airspace information, right? I think it is much more complex, not to say impossible. It requires a change in the BGL files. I know some tools exist to update the obsolete radio frequencies. They also change the BGL files but changing a frequency does not change the size of the BGL file, you just replace a number by another. Updating anairspace is more complex than that, I am afrid it is impossible.

Hopefully someone will tell me I am wrong

Eric

 

[Gypsy Baron]

I know you can create new airspace boundaries with XML code but I
do not know if the new BGL would supercede the original data as I
haven't tested that.

Here are a couple of samples of the XML code to define an airspace:

<?xml version="1.0" encoding="ISO-8859-1"?>
<FSData version="9.0"
xmlns:xsi='http://www.w3.org/2001/XMLSchema-instance'
xsi:noNamespaceSchemaLocation="bglcomp.xsd" >
<Boundary
type="CLASS_A"
name="London CTR">
<BoundaryStart
lat="51.60305"
lon="-0.6925"
minimumAltitudeType="AGL"
altitudeMinimum="0.0"
maximumAltitudeType="MSL"
altitudeMaximum="762.0"/>
<Line
lat="51.60305"
lon="-0.21472"/>
<Origin
lat="51.47"
lon="-0.21472"/>
<Arc
type="CLOCKWISE"
index="0"
lat="51.33666"
lon="-0.21527"/>
<Line
lat="51.33694"
lon="-0.63333"/>
<Line
lat="51.35111"
lon="-0.71166"/>
<Origin
lat="51.47"
lon="-0.45361"/>
<Arc
type="CLOCKWISE"
index="1"
lat="51.60305"
lon="-0.6925"/>
</Boundary>
</FSData

==================================================
<?xml version="1.0" encoding="ISO-8859-1"?>
<FSData
   version="9.0"
   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
   xsi:noNamespaceSchemaLocation="bglcomp.xsd">
<Boundary
      type="RESTRICTED"          
      name="Amethyst A1D HPZ">

<Origin                           
      lat="53.601108379662"
      lon="0.723909884691238"

/>

<Circle
      index="0"
      radius="2780"
      minimumAltitudeType="MSL"  
      altitudeMinimum="0.00000"
      maximumAltitudeType="MSL"
      altitudeMaximum="610.000"/>

</Boundary>
</FSData>

 

[eric_marciano]

Interesting !!
How is this XML used? Is it compiled by some sort of compiler that generates a BGL? (like the scenery creation tools) Or does it update an existing BGL?
Anyway, having the ability to create new airspaces is interesting, but I'm afraid modifying an existing airspace is more difficult...

Eric

 

[Gypsy Baron]

Interesting !!
How is this XML used? Is it compiled by some sort of compiler that generates a BGL? (like the scenery creation tools) Or does it update an existing BGL?
Anyway, having the ability to create new airspaces is interesting, but I'm afraid modifying an existing airspace is more difficult...

Eric

I just drag it onto the BglComp.exe to create the bgl file and then
place that in an activated scenery folder. I don't recall exactly how
I was creating the XML code as my project has been on the back
burner for awhile now.Typically I use SBuilderX to get lat/lon information
by drawing polys. Circular shapes are easy. The XML for irregular shapes
can be rather tedious as I recall.

I've been experimenting with this to create special airspaces that do
not normally display on the GPS that will encompass the various flak
sites I have placed in 'occupied Europe' with my flak package. There
are several hundred of them!

I am planning on adding a gauge that will inflict damage to the A2A
Accu-Sim aircraft as a result of transiting a 'flak zone' and the
outcome of a couple of random number generators.

I needed some way of autonomously determining when the user aircraft
was in the flak, since those are simply effects triggered by proximity
controllers and not detectable through any, simulation variables.
The airspace solution seems to be viable as all I need to do is query
the nearest airspace(s) and when inside one with the 1st 4 characters
of the ID as "FLAK" the damage gauge will go to work.

So far I have some test code for that gauge but haven't written the
airspace detection code yet nor have I fleshed out the damage
infliction code that can be anything from minor fuel/hydraulic/etc
leaks to electrical system failures, loss of engine cylinders, jammed
control surfaces to full blown engine fires.

Paul

 

[mgh]

This thread may be helpful http://www.fsdeveloper.com/forum/showthread.php?t=18385&highlight=airspace

The newBGLAnalyze documentation give deatails of how and where bouindaries are held in the BGL files.

 

[rpmc]

Eric,

I checked my map scale derivations and I come up with the same results and conclusions as before regarding monitor resolution, etc. So, in the for what it’s worth category, here are some observations offered as food for thought:

- Panel.cfg gauge size settings that change the aspect ratio of the native map gauge x, y size as well as monitor aspect ratio affect where the gps.dll CustomDraw places objects on the map (that is, the gauge pixel location or the mouse x and y location of the objects). Even Full Screen View vs Non-Full Screen affects the aspect ratio of the gauge a small amount. In other words, as these ratios change, the mouse x,y location of objects change. Distance ratios are maintained, but absolute gauge x,y (mouse x,y) changes.

- In my specific application, duplication of the real Garmin 500 series Distance Measurement option (calculating distance and bearing to any point on the map that is clicked), normalized map scale functions (NMiles per Gauge Pixel, x and y) must be used that incorporate panel.cfg, monitor resolution and non-full screen corrections for the calculations to be accurate for any screen and gauge size configuration.

- In both FS9 and FSX, the Y axis longitude scale is not quite equal to the X axis latitude scale at the equator. This suggests that if you create an overlay map that fits the underlying fs9gps terrain layer at one zoom factor, it will no longer match as you zoom out if only a single zoom multiplier is applied to both axes of the overlay map. This is a zoom issue, not a latitude issue.

- As a consequence, my guess is that it’s possible that an overlay map calibrated to the underlying gps.dll terrain map at one set of aspect ratios and zoom may no longer coincide with the underlying gps.dll objects as the ratios and zoom change. Of course, I can’t know for sure because I don't know the math that goes into your map, but at this point I think it is a possibility. I need to hear what you say.

- In FSX, no latitude cosine correction is applied at Zoom Factors below 270.

Cheers,

Bob

 

[eric_marciano]

Hello Bob,

I had to slow down my project and could find the time to test it with FSX, but with fs9 I can tell you it works perfect. I don't have to care about the window ratio, the screen resolution nor the windowed/fullscreen mode. As you can see on the testing image sent in my previous post, my own map objets perfectly coincide with the GPS map objects (I checked with the airports only).
I am not a genious, I don't use complex maths, I just made several tests (trial & error) to finally find the same map projection as the GPS. I also found the way the GPS computes its scale according to the range I set, in order to calculate my scale the same way. That's it...

I will soon do the test with FSX. As I have your email address, I will also send you a beta version of my gauge (if you are interested) so that you can test it as much as you want. I think it works perfect, but I maybe wrong, maybe I missed something...

Eric

 

[rpmc]

Hello Bob,

I had to slow down my project and could find the time to test it with FSX, but with fs9 I can tell you it works perfect. I don't have to care about the window ratio, the screen resolution nor the windowed/fullscreen mode. As you can see on the testing image sent in my previous post, my own map objets perfectly coincide with the GPS map objects (I checked with the airports only).
I am not a genious, I don't use complex maths, I just made several tests (trial & error) to finally find the same map projection as the GPS. I also found the way the GPS computes its scale according to the range I set, in order to calculate my scale the same way. That's it...

I will soon do the test with FSX. As I have your email address, I will also send you a beta version of my gauge (if you are interested) so that you can test it as much as you want. I think it works perfect, but I maybe wrong, maybe I missed something...

Eric

Does your FS9 version work at all zoom levels? Try a zoom factor of 1000 (zoom = 1852000). Do the overlay airports match as well as they did when zoomed in? Have you tested your map overlay on a computer with a different screen such as going to a wide format screen (or vice versa)? Different gauge size aspect ratios? If not, then if you get a chance, check it out to see what happens. And definitely, when you get to FSX you will need to calibrate your overlay separately for zooms above and below factor 270.

This is a little bit interesting and I readily admit I might be missing something as well. But, using my approach of measuring specific pixel placement by the gps of objects in a variety of configs and zooms, I would predict that your overlay would not coincide with the gps base with different configurations, zooms etc, not unless you re-calibrate for each config, and even then, I think there will be a slight zoom issue as discussed above. The application/feature I am working on is a little different than your overlay, but the elements seem inter-related. I've checked the pixel placement of the gps.dll map objects on 4 different computers with 4 different monitor resolutions, FS9 and FSX, different gauge aspect ratios, etc. My results are repeatable, predictable, and quantifiable.

Oh well, maybe it's a mystery and I am missing something basic

Bottom line, however, I hope your overlay works well because you have a great looking application! Very nice.

Bob

 

[eric_marciano]

Bob,

I can't answer your question about the zoom factor because I don't know the unit. What I can say is that with my basic gauge size of 500 by 400 pixels and at the maximum range of 320 NM (160 in front of the aircraft and 160 behind), it works perfect. In that case, the zoom factor is 320 / 400 = 0.8 NM per pixel, and I don't need anything higher (more than 320 NM of range is not necessary for me).
I didn't try on several computers but I tried on 2 monitors connected to the same PC. One of them is 1600 by 1200 (4/3 ratio) while the other is 1366 by 768 (16/9). I can try on other computers, I have some at home I will do the test and let you know.
I can also imagine we are both right (or wrong). I mean, if my map object is not absolutely perfect and if there is a 1 or 2 pixels difference at 320 NM range, I will not try to correct it, this is an accepatable error for me.

I thnk you for your nice words about my application. I plan to add the display of the flight plan (if any) and the display of traffic (AI or multiplayer). All this will be fully controlable through XML variables for people who want to reuse my gauge without needing any C/C++ skills.

Stay tuned for the results of new tests...

Eric

PS. Bob, please read your private messages.

 

[Roy Holmes]

X and Y scaling in gps maps

Been following this very interesting thread, especially the scaling issues.

The GPS maps I use have the ability to pick spots with the mouse and get both bearing and distance, plus calculate the lat/lon of the spot and store it as a waypoint in my nav computer.

On a particular test I did, I noticed that the distance I was getting did not agree with the distance on a topo chart, even though the lat lon was correct.

I fixed that issue by making the aspect ratio of the polygon used for the map in the VC exactly the same as the aspect ratio of the gauge background. That way the map was truly square and agreed with the Mouse X,Y numbers.

Roy

 

[eric_marciano]

Roy,
The distance calculation highly depends on the projection system you use, or the projection system the GPS uses... When you have 2 points defined with their lat/lon coordinates, you have several possible distances. As the Earth is (almost) a sphere, you can compute the straight line between the 2 points (the line that goes into the Earth sphere), or you can compute the distance along the sphere, which is appropriate in the case of aviation.
What I understood from the GPS projection system is that a lat/lon difference is made equivalent to a X/Y difference (in pixels) on your screen. It means that if you calculate the distance based on the X/Y positions (in pixels), it will certainly be wrong. Instead of this, you should convert the X/Y position of each point into lat/lon coordinates (using the inverse projection), then compute the great circle distance between the 2 points. I don't have the formula in mind, it is a quite complex one.
I also plan to add this feature in my moving map (it is already included in my ATC Radar), I will tell you if my distance measurement is the same as what the flight planner computes.

Eric

 

[Roy Holmes]

Eric,
I have found that as long as the gps map, as drawn, is square, you do get an accurate range and bearing from pixels. I then calculate the lat/lon from the range and bearing, using the appropriate version of the complex (somewhat) calculations. I use the great circle method even though it is probably an overkill. I guess I could equally have done it the other way round, assuming a flat earth and get lat/lon first then calculate range and bearing. It is just that the way I did it seemed more intuitive to me at the time.

My calculations of range and bearing obviously take into consideration changes in map zoom or range scale and I draw a line to the stored waypoint with a range marker that only appears when the selected map range is greater than the range to waypoint. I can refine the waypoint as range closes, and have a HUD box that sits on the point because it calculates symbol elevation in terms of altitude differential as well as azimuth movement.

My point was that pixel positions as defined by the mouse click only relate 1:1with the map if the Map is truly square when drawn on the gauge

Great work you are doing. I once tried to use an image of a topo map that I could shift according to location. But it was always North up, could only be used at one range setting and its limits caused me to abandon that approach.

Roy

 

[rpmc]

I use the great circle method even though it is probably an overkill.

Roy,

I think you have the correct approach. As well, your calculations will always agree with internal gps GeoCalc distances which are all Great Circle. Consistency with the gps is the goal.

And, I agree with your statement, "My point was that pixel positions as defined by the mouse click only relate 1:1with the map if the Map is truly square when drawn on the gauge".

Bob

 

[eric_marciano]

Give me some time to implement the distance calculation on my moving map and I will let you know how it works. My feeling is that the window size ratio should not impact the distance calculation, but I will tell you for sure when it will be coded.

Eric

 

[rpmc]

Give me some time to implement the distance calculation on my moving map and I will let you know how it works. My feeling is that the window size ratio should not impact the distance calculation, but I will tell you for sure when it will be coded.

Eric

I can get very accurate distance measurements on any shaped map. For example, a X=500, Y=400 map is not an issue, but if in my panel.cfg, I display that 500x400 map as

gauge00=MAP!MAP1, 0, 0, 400, 400

then I find I need to make a correction to get the distances to work out. That is what I was talking about.

Bob

 

[eric_marciano]

In fs9, everything works perfect, whatever the window size ratio, fullscreen or not. The airport positions all perfectly coincide. I have not implemented the distance measurement yet, but I have tested on my 1360 by 768 screen (16/9) and it worked as well:

Regarding FSX, as Bob said, it is really different. The projection system is definitely not the same. I first tested at Toulouse LFBO (low latitude) and it was looking OK, whatever the window size ratio:

Testing at high latitude, a problem appeared, easy to see at EHNC (north of Norway):

Following Bob's advice, I removed the cosine correction on the FSX version, it appeared like this, making me think the problem was solved:

Coming back to LFBO, it appeared the problem was not solved at all:

Before thinking about distance measurement, I have to scratch my head again to find the FSX projection system. I'm afraid Bob was right, the FSX projection system may depend on the screen resolution, window ratio, ...

fs9 is definitely simpler for developers...

Eric

 

[eric_marciano]

I found the trick !!
For a strange reason, FSX changes its projection system over the latitude of 70°N. Unlike what Rob said, it is not related to the zoom factor but (as far as I understood) only related to the latitude.

My first picture shows how it works just below 70° latitude, everything works perfect with the cosine correction:

Now I just move the map down a little bit, just enough to have the map center above 70°, and the GPS map suddenly changes like this... Visually, it is shocking...

It took me some time to understand what had changed here, then I realized the map projection had changed and the cosine correction had just disappeared, certainly to avoid having a compressed map near the poles:

With the meridians/parralels grid, you can easily see the projection has changed, and now my airports perfectly coincide again with the GPS map airports. It is quite strange to the eyes when you move the map, but it works fine, whatever the screen resolution, whatever the ratio, in windowed and fullscreen modes.

Eric