Thank you for using the Bug section, using templates provided will greatly help the team reproducing the issue and ease the process of fixing it.
Are you using Developer Mode or made changes in it?
NO
Have you disabled/removed all your mods and addons?
YES (no change)
Brief description of the issue:
The airport San Martin, Mendoza has the wrong ICAO code in FS2020: It is listed as SATP while the actual code is either SAMI or local identifier STI
Provide Screenshot(s)/video(s) of the issue encountered:
ICAO or coordinates (DevMode > Options > Display position)
SATP
Detailed steps to reproduce the issue encountered:
Select departure airport “SATP” → note the wrong ICAO code “SATP” instead of “SAMI” or local identifier “STI”
PC specs and/or peripheral set up if relevant:
Not relevant
Build Version # when you first started experiencing this issue:
As far a I remember it has always been like that up to the latest version (1.30.12.0)
For anyone who wants to contribute on this issue, Click on the button below to use this template:
Do you have the same issue if you follow the OP’s steps to reproduce it?
Provide extra information to complete the original description of the issue:
If relevant, provide additional screenshots/video:
Current AIRAC in Navigraph holds this airport ICAO Code as SAME.
As mentioned in the other bug report SAME is actually a different airport:
SAME → International Airport Mendoza (a.k.a. El Plumerillo)
SAMI → San Martin, Mendoza (Aero Club San Martin)
Still not fixed. Same issue in FS2024.
Just to be clear. SATP does NOT exist. I have not idea where that code comes from. I believe it has never existed in Argentina.
SAMI however is the correct code for San Martin. It is a public airport. And it is listed at the MADHEL site (the link you provided in the screen shot):
The local 3 letter code is STI and the 4 letter OACI code is SAMI.
Right, but ANAC hasn’t reported the field to ICAO for AIP inclusion per Richard (Navigraph) investigation. Therefore the AIRAC will never define it as an existing facility. It’s up to the host nation civil aviation agency (or equivalent) to report it as existing and what it’s specifications are.
But SATP isn’t in there either. Where does that come from? Shouldn’t they default to the local code then? STI? I mean they seem to have the data that an airfield is there, including the runways. Where does that data come from? Doesn’t it come with a local code?
There’s clearly a mismatch between the sim facility list and the AIRAC. Even Jeppensen (which is better than Navblue FS’20 or Lufthansa FS’24 stock data) doesn’t know it exists under that designator SAMI. The only way to fix that is to get the agency to report it in the ICAO AIP. Assuming it passes whatever real-world data certification happens there, it gets put into the next AIRAC cycle consumed by Lufthansa and Jeppensen and the sim correlates accordingly based on geo-location. If it’s still not fixed by then - it may require a manual intervention by the sim team.
Basically - this is a database and hierarchy issue. The authoritative data IN ORDER is 1. the Bing Map scans and Autogen showing there is an airfield there (which is valid) and then 2. Correlate with AIRAC and match to geolocation. It’s No. 2 where the data integrity needs fixing.
But where does the wrong 4 letter code “SATP” come from?
That I don’t know. But it clearly carried over from base Navdata.
So there must be other data sources used. As it does have airfields displayed correctly that don’t have a 4 letter ICAO code (like the “DOP” airfield from the Aero Club Mendoza that you had also mentioned in the other post). However there seem to be other data sources that provide made up airport codes.
When looking at the local airfields in the FS2024 EFB I have noticed more incorrect 4 letter codes (SAxx):
Besides the wrong SATP already mentioned there are a couple of other ones that caught my eye:
SARD: This airfield does not have a 4 letter code. The airfield is a private airfield from AEROTEC with local 3 letter code “RAE”
SARK: Also does not have a 4 letter code in real life. It is the public airfield of the Aero Club Rivadavia and has a local 3 letter code: RVD
It almost looks like that there is a data source used somewhere that provides these made up 4 letter codes for airfields that only have local 3 letter codes.
I just picked those as an example. There are a bunch of other codes in the screenshot that do not exist. Like the 5 letter codes that start with SA or the SAHA in the upper right corner.
Ok that we have identified that the 4 letter code “SAMI” has possibly not been reported by ANAC in the ICAO AIP - I have updated the bug report to suggest that the airfield should either be listed as “SAMI” or with its local identifier, “STI.”
Even if the mentioned “Navblue FS’20” or “Lufthansa FS’24 stock data” don’t list it as “SAMI,” it should never have been assigned the fake ICAO code “SATP.” Instead, it should have been listed with its local identifier, “STI.”
This issue seems to affect many airfields in the area, if not across the entire country.
In case it’s helpful, here’s the API that provides all the information for the airfields in the country:
https://datos.anac.gob.ar/madhel/api/v2/airports/
Hi again,
MADHEL is the official source for that. So SAMI / STI is the actual ICAO / local database ident that should be used.
Certain databases don’t support 3 letter idents, for those, artificial 4-letter ICAOs need to be generated if not published.
Argentina just needs to document the API link and make it available as controlled source to the data providers.
@ArgieFSPilot How did you get to that link?
1 Like
Yup, that is correct—MADHEL is the official source. @Flusipilotjp: The API link is essentially the back-end of the official MADHEL website, which is at https://ais.anac.gob.ar/madhel/ . I believe their Android and iOS MADHEL apps also use this API. But I am not sure about that.
While there are many positive changes happening in Argentina right now, I have serious doubts that ANAC (Argentina’s National Civil Aviation Administration) will document the API. To provide some context about this agency: it has historically been used by the Peronist youth organization “La Cámpora” as a means to place its members in well-paying positions. This practice prioritized political affiliation with Peronism over professional qualifications. As a result, much of ANAC’s staff lacks the expertise (and willingness) needed to perform their roles effectively.
As a matter of fact, I have first-hand information from a contact at a software provider for a very popular EFB responsible for the Latin American market. They told me they had reached out to ANAC several times and didn’t even get a reply. It’s worth noting that besides being unqualified—many staff members don’t even speak English—the Peronists are also nationalists who tend to view American companies unfavorably.
Hoping that they will all be fired soon, it’s clear that it will take some time to get ANAC back on the right track. Until then, don’t expect them to document the API anytime soon.
