Airspace information

[rpmc]

I am writing a moving map gauge that uses the GPS information, it is almost finished. I still wonder if it has any interest, but I wanted to know what was doable with the GPS information.
Anyway... My idea is to use the GPS terrain display and draw my moving map on top of it. I didn't do it yet but it shouldbe done in the coming days. The only problem I have is that my map is updated in real time while the GPS terrain is updated only once per second (approximately). The result is a desynchronized updated, but it is not that bad...
I will provide a screenshot as soon as my moving map is finalized, hopefully very soon.

Eric

Yes. I, for one, would be very interested in this. Your code will render all layers except terrain which the gps.dll will handle? I'm interested in your decluttering approach as well as the scaling and zoom algorithms used to match your map with the gps.dll, and various monitor resolutions and gauge sizes.

Are you wrting this for use with FSX only, or also with FS9?

You have chosen a great project!

Bob

 

[WarpD]

No, but it extracts all the other BGL information (airports, runways, ILS, VOR, NDB, intersections, airspaces). I guess this is also copyrighted...
BTW, RealityXP released a TAWS gauge that displays the terrain elevation. RealityXP did a great job decyphering the BGL data to extract this information in real time, and they never had any problem with Microsoft or Jeppesen.

Eric

Airports, runways, ILS, VOR, NDB, intersections... already accessable via the GPS interface... so might be difficult to defend someone doing a direct extract from the BGL... if that was really necessary. Airspaces... not available and thus is definitely going to be 'suspect' to use a phrase.

As for RXP... I can't discuss them other than to say like any large corporation Microsoft isn't very fast when it comes to chasing down legal issues. However, it doesn't mean they don't chase them down. I've seen them do it in the past.

I would not predicate anything I made for a living based on violating someone else's copyright. It's a personal ethical position.

 

[JB3DG]

My plans involve DirectX which is a lot easier on frames than GDI+ DrawImage() functions. I think im getting closer to the secret....

 

[eric_marciano]

Yes. I, for one, would be very interested in this. Your code will render all layers except terrain which the gps.dll will handle? I'm interested in your decluttering approach as well as the scaling and zoom algorithms used to match your map with the gps.dll, and various monitor resolutions and gauge sizes.

Are you wrting this for use with FSX only, or also with FS9?

You have chosen a great project!

Bob

Indeed, I have created a simplified version of the GPS to keep the map only, with or without terrain (maps without terrain shows rivers, coasts, boundaries, ...), with or without airspaces. On top of this, I draw my C++ gauge. I still have some problems and the graphics are not fully readable when the terrain is displayed, but it begins to work.

This is how it looks:

In order to check the right positionning, I have displayed the top down view next to it. You can see it just works perfect because the map center and the zoom factor are aligned (between GPS and my gauge).

Here is another view that I like, more detailed:

Screenshots made with fs9 but the code is designed to work with FSX as well (it uses only standard calls to the SDK). It should work the same in FSX, not tested yet.
I'll let you know more when works goes by, if you're interested

Eric

 

[rpmc]

Screenshots made with fs9 but the code is designed to work with FSX as well (it uses only standard calls to the SDK). It should work the same in FSX, not tested yet.
I'll let you know more when works goes by, if you're interested
Eric

It looks very good and is quite interesting. So, too, are Ed's comments which I am sensitive to especially since my son is a Google software engineer and they also take those kind of things seriously. But, scale is important and I suppose MSFT usually has bigger fish to fry than legacy flight sim code even if the principal is the same.

Speaking of scale, I am interested in your scaling method / approach. The map scale algorithms differ between FS9 and FSX. In FSX, for example, no latitude cosine correction of "X" axis scale is made at Zoom Factors less than 270, but in FS9, the cosine correction is applied at all Zoom Factors. I believe the layers that your code renders wold have to keep up with this...

Bob

 

[eric_marciano]

Speaking of scale, I am interested in your scaling method / approach. The map scale algorithms differ between FS9 and FSX. In FSX, for example, no latitude cosine correction of "X" axis scale is made at Zoom Factors less than 270, but in FS9, the cosine correction is applied at all Zoom Factors. I believe the layers that your code renders wold have to keep up with this...

Bob

What is a zoom factor of 270? I mean, whatis the unit?
I was not aware of the different corrections in fs9 and FSX but anyway, I cannot be 100% sure that the projection system used by the GPS map is the same as my projection system. The most important for me is to have a consistent display near the center of the map. I will do my best to make it accurate but I cannot change the way the GPS draws themap and terrain... To be honest, my moving map was not initially supposed to use the terrain display, for me it is an "eye candy" more than a strict cartographic display.

Now I have other problems to solve about the display. To keep it simple, I use 2 gauges (same position, same size) drawn on top of each other. I causes some strange display problems, like my map objects that take some time to appear the first time, or they disappear when I change a view setting, ... Maybe I will have to do the same as the ATC Radar: create a module that I call from the XML code. I wanted to avoid this solution because it is more complex, but I will not escape...

Eric

 

[rpmc]

Zoom units are distance per pixel. I use NMile per screen pixel or, most frequently, NMile per gauge pixel (gauge x,y size units) after gauge and panel background size and monitor resolution are normalized. NMiles per pixel is a linear function of zoom in both FS9 and FSX throughout all permissible zoom values, the N-S "Y" function is different than the E-W "X" function, and the FS9 functions are different than the FSX functions.

If the base layer is the stock gps terrain map, then I understand when you say one can't change the way the gps draws the terrain other than by changing zoom. However, I think what you can do is use the gps's scale functions to make an overlay drawing scale conformable with the gps rendered base terrain layer no matter the zoom factor, gauge size, monitor resolution, etc.

Bob

 

[eric_marciano]

Obviously, I also have a zoom factor, which depends on the size of the displayed gauge. It is easily calculated with min(width, height) * range. The range is selectable by the user and the gauge can be resized at any time, so the zoom factor is highly dynamic. This is not a problem. And the GPS terrain display does NOT depend on my zoom factor, it just depends on the range. I apply the same range to the GPS display and the gauge size is the same, so the zoom factor computed by the GPS is obviously the same, and it works perfect.

I will make a new test at high latitudes to see if it is still consistent and let you know.

Eric

 

[eric_marciano]

No need to go far to the North, just the north of France shows the problem...
As you can see on this image, it is now obvious that the GPS does not use the same projection system as mine, which causes problems at long distance from the map center. With a range of 80 NM, the problem appears: some airports and VORs are in the sea between France and England...

In addition, look at the position of Le Havre Octeville airport (LFOH), it is wrong. I mean... the position is right but it is not consistent with the terrain display. I know this because I flew there (in real) some years ago Now if I move to LFOH, the airport is close from the map center (the aircraft) and its position looks perfect:

As I can't change the GPS internal code, I have only 2 solutions:
- I remove the ability to display the GPS map and terrain below my moving map (it means I also get rid of the airspace display)
- I limit the max range so that the display looks OK even if it is not really OK.

Both solutions look bad to me...
If you have another idea, please let me know.

Eric

 

[eric_marciano]

I did some additional tests, and th reality appeared to me !! It is so obvious that I should see this earlier... Look at the picture comparing my moving map and the fs9 map (same as the GPS display): my meridians and parralels are not straight lines, my projection system make them appear as curve because the earth is a sphere, but the fs9 map shows straight lines parallel to each others.

Their project maintans angles, my system maintains distances. I don't remember the name of each system, but they are definitely different.

Last possible solution: change my projection system to fit the GPS. I have to change my projection calculation for this, not easy

Eric

 

[rpmc]

Eric,

I've never worked with cartography and map projections before so you know substantially more than me ... actually, I don't really know what I am talking about at all, not yet anyway, but after googling around a bit, it seems to me that FS uses a simple cylindrical projection.

http://www.progonos.com/furuti/MapProj/Normal/CartHow/HowER_W12/howER_W12.html

And I believe the real Garmin series 500 gps's, after which the FS9/X gps_500 gauge is modeled, do it the same way.

However, I have spent some time tearing into the gps module including its map operation, and that is why I was curious about how you handle scale if you layer your map over the FS gps terrain. I said "scale" but now I see that I would need to ask about "projection" too.

While looking into CustomDraw – Map, one thing I wanted to replicate was the real Garmin 500 Distance Measurement option (ability to click on any pixel on the map and return distance and bearing from the aircraft or reference point) which isn’t available in the MSFT replica gauge. To accomplish this, I needed to derive the map "X" and "Y" scale formulas which I have done for FS9 and FSX. Here's one example:

In the course of this effort, I discovered that a handful of things other than zoom factor affect the scale displayed on the screen, including monitor resolution, background panel bmp dimensions, gauge native size and enlargement, windowsize_ratio, latitude, FS9 vs FSX, and even Full Screen vs Non-Full Screen View. I’d be surprised if I have approached this in the proper, most elegant way, but my “click” distance measurements are less than 0.3% different than the fs9gps GeoCalc measurements over all permittable zoom values, monitor types/resolutions, etc. I think that's as close as my pixel resolution will allow.

Anyway, I have begun to get a feel for how (where) CustomDraw – Map places objects on the map image at any zoom (range), any latitude, any resolution .... If you ever decide to change your map projection method to match the fs9gps, I’d be happy to give you what I’ve got if you want. Maybe it would be of some use.

Bob

 

[eric_marciano]

Thank you, Bob, your link definitely helps and will certainly allow me to change my projection system so that it fits the GPS display. Regarding the distance measurement, I really don't understand why the screen resolution, full-screen view and window ratio have to enter in the calculation?!?
IMHO, the distance calculation is just based on a number of pixels and on the scale (which is calculated with the gauge size and the range). As far as I understand, no need to take into account the screen resolution, full-screen, etc. Maybe I'm wrong here...
I will soon try to change my projection system according to the information you have provided. I will let you know if I may need some help from the development you have done but I should be OK.

Anyway, I thank you for proposing your help

Eric

 

[rpmc]

yeah, what you're saying makes sense, so I am surely over looking or over analyzing something with regard to resolutions. Need to double check several things.

Besides that however, clearly FS9 and FSX have different scaling functions.

Good luck with the new projection, I'm sure you'll have a revised map up and running soon

Bob

 

[eric_marciano]

I have changed my code to change the system projection, while keeping the other one as an option. It looks OK because the grid lines (meridians and parralels) are now horizontal and vertical straight lines, but there are still problems with the objects that are far from the map center. See the image:

Maybe something is wrong in my projection, but I can't see it...
I'm helpless now...

Eric

 

[Roy Holmes]

Eric,
In the SDK folder select fsxsdk.chm, then the Terrain and Scenery section, click on the link to Base file information. That will show you how the scenery and map grid works.

Then using TmfViewer navigate to the FS Scenery \ 0501\scenery and open cvx4713.bgl. You will recognise where you are. You can center the map by clicking on a point.

The lat/lon grid lines are squares like the map display in FS. The pixel difference between points represents their difference in latitude and longitude, not their relative distance and bearing.

Your map overlay looks like a Lamberts Conformal Conic Projection. In a conformal map, the pixel difference between points represents their difference in distance and bearing, not their difference in latitude and longitude.

If you overlay a grid map on a conformal map you are only going to find they agree at the equator. It is as simple as that.

Roy

 

[eric_marciano]

Roy,

I will look at the information you are pointing, I thank you for this.
In the meantime, I realized the problem I have is not that bad, it is just a problem of scale calculation. It appears I don't calculate the scale the same way as the GPS display. When objects are close to the center, the scale error is low and almost invisible, but the further the objects from the map center, the more the error appears. I saw that by letting the GPS display the airports and realized they don't correspond to my displayed airports.

Regarding the projection, I have no problem any more. Indeed, I used to have a conic projection that looked like this:

In order to be compliant with the GPS display projection, I changed it to a cylindrical equidistant projection where the pixel position depends on the lat/lon difference, something like this:

It works fine, as you can see on the image I posted yesterday (above). It is especially easy to see this with the meridians/parallels grid that appears as squares. I must say that my grid is drawn by computing the pixel position of each intersection between meridian and parallel, so that the appearance of the grid changes when the projection system changes.

Now I just have to understand how the GPS computes its scale (the number of pixels that correspond to a lat/lon degree) and I will be done

Eric

 

[rpmc]

Now I just have to understand how the GPS computes its scale (the number of pixels that correspond to a lat/lon degree) and I will be done

Right. And that's what I have done, measuring directly from the gps map when FS9 and FSX are running. I use NMiles per Gauge pixel, but it could just as easily be Lat/Lon degrees per Gauge pixel because of the cylindrical projection scheme.

The X and Y scales are linear functions of Zoom throughout all permissible Zoom values, the X axis scale appears to differ slightly from the Y axis scale even at the equator, FS9 differs from FSX, and in FSX, there is no latitude cosine correction applied to X axis scale at Zoom Factors below 270. I think that last thing was necessary to get the Range circle feature in FSX to be somewhat accurate at arbitrary latitudes at least when zoomed in. As mentioned above, I'm still verifying some things.

If you can find reference somewhere to the equations MS uses for scale as a function of zoom, that's ideal, but good luck. I admit I didn't dig very deep on that. Alternatively, you could derive them yourself in an experimental manner as I have done and the results can be pretty accurate. Of course, there always could be a better approach that I have missed. Have fun.

Bob
_____________________________

In the map gauge below, I can click anywhere on the map to find its distance or lat/lon and bearing relative to a reference point elsewhere on the map. In this example, the reference point is the FCOM airport on the left side of the map, and the clicked point (the red dot at mouse 446.618 X, 202.312 Y) is the HKKI airport on the right. Using scale functions I derived, the clicked point is 1149 NMiles at 90 degrees true from the reference, as shown in the yellow highlight box at 3 o’clock on the gauge. That matches the fs9gps GeoCalc distance and bearing calculation results displayed at about 8 o’clock on the gauge. This can be done at any Zoom because Scale vs Zoom Factor formulas were derived. It’s as accurate as my screen resolution / mouse cursor capabilities allow – the computed distances using the derived scale formulas are less than about 0.3% different than the GeoCalc distance calculations.

Thanks are owed to Tom Aguilo and Robbie McElrath for use of their XMLVARs and LOGGER modules in this gauge. This map test gauge isn’t possible without those modules.

 

[eric_marciano]

Bob,
You're right, and now I understand your first post in this discussion regarding the scale... Your screenshot is very interesting. What tool do you use for this? Is it a gauge that you developed? If I can get it somewhere, it would definitely help me.

Eric

 

[rpmc]

Bob,
You're right, and now I understand your first post in this discussion regarding the scale... Your screenshot is very interesting. What tool do you use for this? Is it a gauge that you developed? If I can get it somewhere, it would definitely help me.

Eric

Eric,

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.

I added a few words at the bottom of my previous post that reveal the simple approach I used to derive scale formulae. Simple in approach, but by now, I have measured at least a thousand points in FS9 and X, on different computers, OS, and monitors, different cfg settings, etc. So, I might have shorted some wires along the way regarding monitor resolution, but I will straighten that out and then if you want, I can flip you a copy of the gauge. It's all XML of course, and you'll need XMLVARS and LOGGER.

Bob

 

[eric_marciano]

Bob,
I have just realized you are the author of the GPS Guidebook, excellent work !!
I will try to make my moving map work, I think I found a way of measuring distances and angular distance in a fancy way (in C++ of course...).
I'll keep you posted, hoping I will soon be able to send yo a copy, if you are interested of course

Eric