Need airspace boundaries for online networks

[albar965]

Will check for 2.8 (and next 2.7 alpha):

• [X] Import IVAO boundaries from JSON
• [x] Import VATSIM centers GeoJSON from VATSpy Data Project. I suppose this is the official source. Anybody please interject if not.
• [x] Resolve current Online Center (updated periodically while flying) names to geometry fetched from above

---

Old Notes

LNM displays online centers as circles since the real boundaries are not available to me.

A new feature was introduced in the 2.4 LNM versions which allows to assign real boundaries for centers:

See Online Airspaces.

I do not have access to these files from the online networks. Note that the files have to be in OpenAir format.

I'd like to put package in the littlenavmap.org download section if somebody can provide this data to me.

[ltoenning]

Speaking for VATSIM: This might be difficult. Normally all countrys managing their own sector-file which containing all sectors with different dependencies. (I haven't checked if LNM can handle these). So there isn't a central place where all sectors-definitions are available.

Recently many vACCs started to use a tool called GNG (Global NAV Generator) which has a global database where every vACC can edit their sectors. Sector-borders where fitted with edits of the neighbour-vACC. Most of the vACCs using this are listed here: http://files.aero-nav.com/

This datafiles aren't in OpenAir format so far, but I can try to contact the GNG-admin if he can implement a OpenAir-format exporter.

[albar965]

Hi Lars, thank you for the link. This looks like the best collection so far. I know the used format (the name slipped my mind at the moment, LOL) and plan to support it in future versions for user airspaces in LNM.

Providing the data in OpenAIR format would be terrific since it would enable this functionality for users right away. Would be great if you could ask the admin. Alex

[b-faller]

So I did some work and wrote a small Python script to convert the data from the VATSpy Data Project into the OpenAir format. So far it works okay but there is still room for improvement.

Preview:

However, a couple things would be nice to have:

• Many mappings for prefixes are missing in the original dataset so CLE_04_CTR does not point to the KZOB airspace boundary and is therefore not rendered. I added a small custom_mappings.json to be able to fix some of these issues. A better way would be to use only prefixes for matching instead of exact matches for each airspace, e.g. if an airspace named CLE_S exists show it for all callsigns/positions on VATSIM starting with CLE_S and an airspace named CLE matches all other positions starting with CLE. Basically a longest prefix match. Maybe the same for a suffix could be helpful too for different airspaces based on FSS/CTR? I think something along CLE_S_CTR (exact match), CLE_S* (prefix match), CLE_S*FSS (prefix and suffix match) would do well.
• The ability to designate UIRs airspace as UIR airspace type which is already in LNM. Maybe this is already possible via OpenAir?
• Instead of creating the same airspace for all callsigns/positions, define a mapping table so that multiple callsigns/positions can share the same airspace definition because the current file contains already around 100k lines …
• Maybe increase the zoom level at which online airspaces show, for centers I think it's a bit low?

I did put the script on GitLab if you want to take a look at it.

[albar965]

@b-faller Thank you a lot and sorry for the late reply. I'm currently in MSFS adaption and bug fixing craze for LNM. Give me a few days and I'l have a look at it. Is there also a way to extract IVAO data?

[b-faller]

@albar965 No problem, that's more important right now for sure. I did setup CI so that it always builds a user airspace file every 30 days so that it incorporates changes from upstream. I haven't found a way to run it on each upstream commit yet, if anyone knows how to do that please chime in. Anyway, a current file should now always be available here.

IVAO works mediocre because most centers share the callsign so it uses the same definition from VATSIM. As long as the airspace is identical for IVAO and VATSIM this should not be a problem, however, if they would not match the airspace boundary for some reason (maybe due to differing area of responsibility?) I can't solve this without a change in LNM or separate files (the callsign -> airspace mapping is shared/non-injective between IVAO and VATSIM airspaces). For IVAO I also don't have public sources.

[paulparkervogo]

file provided by b-faller was very useful as I see many airspace boundaries of online centers on VATSIM. However, as already pointed out by b-faller is many centers have different callsigns for same airspace. For example I see HOU_CTR correctly, but when the controller logs in as HOU_81_CTR, I see a big circle. I would like to suggest provide an editable field after callsign in Online Centers table where user (in this case me) can add the binding. For example, whenever I see a big circle where i expect to see a boundary shape of center, I can go and add the actual airspace name from the airspace file.

For example if I see HOU_81_CTR, I can add HOU_CTR in the editable field next to it to get correct airspace. You can save the binding in a file automatically per callsign.

[albar965]

@paulparkervogo I'll see what can be done. Best way is to apply some automatic/fuzzy matching. Maybe allow a user to add matches center<->callsign manually as well.

[Quentin-M]

Hey, inquiring on whether there's been any movement on this. I believe this is the most requested feature on LNM!

[albar965]

Hey, inquiring on whether there's been any movement on this. I believe this is the most requested feature on LNM!

I plan to look into this for 2.8. I certainly have the data for IVAO (but not the import code yet). Will also look into the Vatspy project linked above. But no promises as usual.

[Quentin-M]

Thanks a lot @albar965!

I've chatted briefly with Mark at Volanta who said that SimAware (map.vatsim.net) apparently led an initiative to publish some of the USA APP sectors publicly, which is why they display the best boundaries.

I have also dug into the way SimAware fetches the data, find below all of the relevant endpoints: https://map.vatsim.net/livedata/firboundaries.json https://map.vatsim.net/livedata/traconboundaries.json https://api2.simaware.ca/api/livedata/countries.json https://api2.simaware.ca/api/livedata/firs.json https://api2.simaware.ca/api/livedata/uirs.json https://api2.simaware.ca/api/livedata/live.json https://api2.simaware.ca/api/livedata/onlinefirs.json https://api2.simaware.ca/api/livedata/tracons.json https://api2.simaware.ca/api/livedata/locals.json https://api2.simaware.ca/api/livedata/sigmets.json https://api2.simaware.ca/api/livedata/airports.json

[albar965]

Thanks for the links.

[albar965]

@Quentin-M and @b-faller Unfortunately I cannot find anything that allows to connect the callsigns from vatsim-data.json to the boundary files. Boundary types are also missing. No idea how to fix this for VATSIM.

[b-faller]

@Quentin-M and @b-faller Unfortunately I cannot find anything that allows to connect the callsigns from vatsim-data.json to the boundary files. Boundary types are also missing. No idea how to fix this for VATSIM.

The callsigns can be connected with this API endpoint: https://api.vatsim.net/api/map_data/. Specifically the VATSpy.dat file. In it there are two sections [FIRs] and [UIRs]. They have the structure:

ICAO	Name	Callsign Prefix	Fir Boundary
EDGG-K	Langen Radar (Kitzingen) - Langen	EDGG_K	EDGG-K
EDGG	Langen		EDGG

The callsign prefix is used to map to the boundary. The field is sometimes empty like in the example above. In this case the ICAO field could be used.

[albar965]

The callsigns can be connected with this API endpoint: https://api.vatsim.net/api/map_data/. Specifically the VATSpy.dat file. In it there are two sections [FIRs] and [UIRs].

Thanks a lot for your answer. I somehow got lost in the structure.

So I can get a center from vatsim-data.json, the frequencies from transceivers-data.json and the boundary from firboundaries.json.

"callsign": "LZBB_CTR" from vatsim-data.json would translate to "id": "LZBB" in firboundaries.json, right?

I suppose there is no geometry for TWR and the like and there is not always a boundary for each center.

What about approach and departure in traconboundaries.json? I could not find any matching approach and departure centers in the TRACON boundaries.

[b-faller]

So I can get a center from vatsim-data.json, the frequencies from transceivers-data.json and the boundary from firboundaries.json.

Yes, although the VATSpy.dat sometimes provides an additional mapping (callsign -> boundary ID). So to get the right boundary the process would be: vatsim-data.json -> VATSpy.dat -> FIRBoundaries.dat/firboundaries.json I suppose? The boundaries are also provided by the same API endpoint for VATSpy.dat (https://api.vatsim.net/api/map_data/) but I don't know what the difference besides the format (.json/.dat) is.

By the way, UIRs are also another thing since they are comprised of FIRs. For example they look like this in VATSpy.dat:

EDUU|Rhein Radar|EDGG-D,EDMM-G,EDMM-R,EDGG-B,EDGG-R,EDGG-G,EDMM-Z,EDWW-B

Unfortunately I have no idea whether they point to the ICAO field within [FIRs] in the same file or directly refer to a boundary ID.

What about approach and departure in traconboundaries.json? I could not find any matching approach and departure centers in the TRACON boundaries.

I did not know about this endpoint but the JSON returned has a prefix field for each item:

Maybe this is interpreted as a callsign prefix from vatsim-data.json?

[albar965]

@b-faller Thanks again. Will check. Is there documentation for the VATSpy.dat around?

[b-faller]

@albar965 No problem, ping me if you have additional questions. I don't know of any documentation beside the comments in the file itself and the repository. All I know was more reverse engineering for the demo script I wrote mentioned above than anything else ...

[albar965]

Thanks for the help, all. I implemented the reading of the JSON data now since this is easier to parse. Have to see how many boundaries match.

@Quentin-M One question: Who owns the data or who is the responsible contact? Or is the data free to copy and mirror?

[albar965]

[albar965]

Doing ok so far. Not all airspaces resolve.

[b-faller]

This is awesome, thank you for your time and work!

Not all airspaces resolve.

Do you have some examples which airspaces won't resolve? Maybe I can take a look.

[albar965]

Do you have some examples which airspaces won't resolve? Maybe I can take a look.

Right now based on current vatsim-data.json, atc_positions.zip at 05.03.22 14:50 UTC:

1. EDGG_NDH_CTR
2. LECM_R2_CTR
3. LFFF_MIL_CTR
4. LIRR_NE_CTR

Seems the suffixes are missing. Not sure if I should do a query without suffix again. How to resolve duplicates then?

Alex

[b-faller]

Right now based on current vatsim-data.json, atc_positions.zip at 05.03.22 14:50 UTC:

1. EDGG_NDH_CTR

2. LECM_R2_CTR

3. LFFF_MIL_CTR

4. LIRR_NE_CTR

Seems the suffixes are missing. Not sure if I should do a query without suffix again. How to resolve duplicates then?

Alex

Are those listed callsigns derived from the atc_positions.zip or the actual callsigns that were online from vatsim-data.json?

I briefly checked the content of atc_positions.json for the EDGG example and the middle identifier is wrong for many stations. The VATSIM wiki page lists valid callsigns on the network such as EDGG_D_CTR (Dinkelsbühl). If you build the callsign prefix from atc_positions.json with <center_id>_<middle_identifier> this station would wrongly be EDGG_DKB_CTR and won't match.

Where does atc_positions.json come from? The data at https://api.vatsim.net/api/map_data/ has the correct callsigns.

[albar965]

Where does atc_positions.json come from?

Sorry. Wrong file from IVAO data. It seems like every minute of programming ages my brain for days. :upside_down_face:

I use these files https://map.vatsim.net/livedata/firboundaries.json https://map.vatsim.net/livedata/traconboundaries.json for testing.

[albar965]

@Quentin-M How often do the files https://map.vatsim.net/livedata/firboundaries.json https://map.vatsim.net/livedata/traconboundaries.json change? Is it ok for the LNM user to download and install it manually every few days?

BTW: Just made the matching more error tolerant by trying the variants below:

1. EDGG_DKB_CTR
2. EDGG_D_CTR
3. EDGG_CTR

Alex

[Quentin-M]

Absolutely no idea as I don't own those services. I will say though that those are all the files that are loaded every time anyone loads https://map.vatsim.net/ in their web browser so it's got a good amount of traffic.. I don't think anybody would even notice the difference your periodic pulling would do in terms of traffic / load.

[albar965]

Ok. Thanks. I'll contact them.

[b-faller]

BTW: Just made the matching more error tolerant by trying the variants below:

1. `EDGG_DKB_CTR`

2. `EDGG_D_CTR`

3. `EDGG_CTR`

Great so the DKB that did not resolve was IVAO only? If I search both JSONs (firboundaries.json/traconboundaries.json) I don't find DKB or other middle sections you said were not matched.

Does the current implementation of fuzzy matching support extensions such as _1 or 2,3,... as in EDDS_TWR to EDDS_1_TWR which is sometimes used during shift changes to work around the fact that connected ATC callsigns must be unique? I've seen multiple underscores being used as well e.g. EDGG_K__CTR.

[albar965]

Great so the DKB that did not resolve was IVAO only?

No. There are also missed with VATSIM data. Approach and departure do not match anything. Some centers are not available like LON_SC_CTR.

I just added replacement of multiple underscores. The numbers as middle extension should be caught by the case 3. which always removes the middle part and queries again.

I'd be really happy to get more reliable data for VATSIM.

Alex

[Gulliver54]

Hi Alex,

Great stuf. Downloaded IVAO ATC boundaries and they seem to work. Thanks.

[Gulliver54]

Hi Alex, Although the file is loaded inside Folder "user airspaces", only unticking "online airspaces" will disable these boundaries. No big deal, and thinking about it, most likely these boundaries will belong to the online airspaces.

[albar965]

Hi Alex, Although the file is loaded inside Folder "user airspaces", only unticking "online airspaces" will disable these boundaries. No big deal, and thinking about it, most likely these boundaries will belong to the online airspaces.

Internally they are treated as online airspaces. I think this is ok to put them into the online category.

[vapouryh]

Hi there, I've had a thorough look throughout the thread and have got LNM to the point where it can pretty much all of europe's online vatsim airpsaces for centers and approach/departures. I get that tower and ground don't have any sort of boundaries and that's fine, the only two things I have issues with is getting US approach and departure boundaries to show as well as EUROCONTROL boundaries and also showing RSTR areas on the map. With the RSTR, it will show up using the Simulator airspace library but then inteferes with my online boundaries... this isn't such a big issue though so i'm not that bothered if it's something hard to fix. Many Thanks.

[albar965]

With the RSTR, it will show up using the Simulator airspace library but then inteferes with my online boundaries... this isn't such a big issue though so i'm not that bothered if it's something hard to fix.

Sorry, but I have no idea how to remove the duplicates or merge the different airspaces.

[vapouryh]

With the RSTR, it will show up using the Simulator airspace library but then inteferes with my online boundaries... this isn't such a big issue though so i'm not that bothered if it's something hard to fix.

Sorry, but I have no idea how to remove the duplicates or merge the different airspaces.

Any idea on how to get the boundaries for USA approach/departures though?

[albar965]

Any idea on how to get the boundaries for USA approach/departures though?

You can try https://www.openaip.net/

[vapouryh]

Thanks for the reply, after having used the traconboundaries.json I now get all of them show up in the US. Cheers.

[maszat]

@vapouryh or @albar965 would you please share a little more details. I have firboundaries and traconboundaries in the user airspaces folder, but that itself did not resolve the US approach/deparure display ( still only circles ) and some ( not all ) US centers are also still only circles. Probably important to mention that under the menu item "Airspace Libraries" I only selected "Online". The reason is that if I select "User" also, then it does display more centers and of course more accurately outlined, but that defeats the purpose since those may not be online. I try to mimic the behavior of how the SimAware website displays centers/approach - that website somehow does a very good job. I wonder if SimAware identifies the approach by it's id such as "A90" and not by callsign "BOS_APP", the former being pretty unique vs callsigns with variations. One may ask, why don't you use SimAware only in that case? LNM has a major benefit here: when the sim is running, all the in-range airplanes get a near real time position update ( sim to LNM ). SimAware airplane positions are much delayed. Any help appreciated, pilots. Thanks and regards.

[albar965]

See last chapter Online Airspaces here: https://www.littlenavmap.org/manuals/littlenavmap/release/latest/en/AIRSPACELOAD.html

The callsign approach does not work for all airspaces. A lot remain circles, unfortunately.

Where is the id stored? Do you have an example file?

The problem is that LNM tries to match airspaces for VATSIM and IVAO which come in different flavors.

[maszat]

I looked at various json files. It appears to me that the boundary id (e.g. "A90") is only used as a label on the map. There is a Github project that I just recently found

https://github.com/vatsimnetwork/simaware-tracon-project

in their documentation they explain how SimAware determines Tracon boundaries. Simply by deduction, if their online map looks visually pretty good in most cases (best I've seen), given that the json file seems to describe the app/dep boundaries, then I assume their matching logic works well.

Kindly look at this and see if it may help to get rid of more circles. In the LNM settings the user makes a selection whether he uses IVAO or VATSIM, which allows me to think that the matching logic may not need to be identical for both, if you wish to implement it that way. The necessary json files to download remain the responsibility of the pilot. best regards, much appreciate your LNM!

[albar965]

Ok. Will have a look at this.

[maszat]

Alex, happy new year, I revisited this topic with the latest 3.0.1, imported the traconboundaries.json and firboundaries.json, and it seems to have loaded perfectly, the screenshot shows that all the approach boundaries look pretty good. I think this is now just a matter of a little magic of yours to do the fuzzy name matching for the VATSIM online approach/departure controllers. thank you

[albar965]

Alex, happy new year, I revisited this topic with the latest 3.0.1, imported the traconboundaries.json and firboundaries.json, and it seems to have loaded perfectly, the screenshot shows that all the approach boundaries look pretty good. I think this is now just a matter of a little magic of yours to do the fuzzy name matching for the VATSIM online approach/departure controllers. thank you

A Happy New Year to you too!

I'll have a look at this. Maybe can sneak it into 3.0.2.beta but no promises.

Alex

[albar965]

Now ignoring the middle suffix like the O in EDMM_O_CTR when looking for airspaces. Looking better but still not complete. Using https://map.vatsim.net/livedata/firboundaries.json and https://map.vatsim.net/livedata/traconboundaries.json in the screenshot below:

[maszat]

very nice. Europe (for some reason) has always looked better, even in the earlier version, I will check with US departures and centers (when 3.0.2 comes out). Thank you for the effort!

[albar965]

Yep. It's more sparse in the US. I also tried the files from the SimAware TRACON Project but this has less boundaries and less matches.

[maszat]

when I looked at the us departures map (as loaded from the json) it has a ton, and it must match all that VATSIM uses - this feature will not aim to match real life, I assume, rather provides VATSIM compatibility

[albar965]

The boundaries are really missing if they are not shown. I look only for prefix and suffix now.

[maszat]

understand, currently I can't imagine a scenario where that logic will not help.

[maszat]

thank you for 3.0.2, Alex! First test results - including some manual data edits for the screenshot

A90_APP (Boston Approach) looked great - here the ID and 'prefix' data values were identical.

NY_APP did not resolve - the reason is that ID value matching takes priority over 'prefix' value matching.

BOS_CTR did not resolve - most likely only manual data fixing is an option for the users, however this is relatively painless, no complaints.

Recommendation : for traconboundaries let the 'prefix' value matching take priority, and fall back to ID value matching if needed. However, manual data fix is an option for users here. Still relatively painless, just a bit more work than for centers.

Recommendation : please allow _FSS and _SUP postfixes in addition to _CTR for the firboundaries. Manual data fix is not an option for this case. Allowing _DEP postfix in addition to _APP is a nice touch also.

Love it, this is already very useful!

best Kornel