Closed ghost closed 1 year ago
hey. have you got a screenshot of what this looks like?
I believe there are quite a limited number of available colours for ground maps.
Hi Pheonix,
I fail to see why this feature would be needed. If a controller is unsure of runways they can easily add them as a text field using F9. Is there a reason you want to add this map?
Should a "Community Additions/Mods" Maps Folder be introduced? The decision to include individual maps will stay with the AIS team, if they see fit to take over a project or remove an abandoned project that remains up to them.
This should ideally imply to users that the provided maps are not created/maintained by the AIS team yet have at a minimum are not malicious or include any egregious errors. Including this with the core australia-dataset would also allow for updates to be pushed along side major airac changes when noticed.
The maps won't be activated by default, optional and out of the way.
Sorry, accidentally closed this.
We are currently discussing your idea with the team.
I'm not opposed to a community maps folder! We do need to be sure of the validity of the data in the dataset still though. I believe @vatpacais (Peter) said the runway thresholds could be extracted from the DAH.
We may also be able to extract the gate information from the DAPS (example https://www.airservicesaustralia.com/aip/current/dap/PADAP02-159_08SEP2022.pdf) but this would still be a semi manual process.
I would prefer to leave the decision on community maps, etc to the new ais manager (whoever/whenver) they are appointed.
This map was created using the data found within TCU maps, they primarily source data from the DAH from my understanding. Using the DAH's data to recreate this map would take a considerable effort using my current manual processes and make identifying airac changes difficult.
The Gate Information's (bay_numbers) data was compiled directly from the DAPs (along with the TERMA for mil/joint bases), with minor adjustments after discovering inaccurate/imprecise coordinates in the source data.
I was unaware the runway thresholds were also locate inside the DAH, if the ais team was to assume responsibility for the map the data could be inserted in the TCU maps as a separate ground map entry using the processes already in place.
Producing and maintaining this map can easily be automated using the data already automatically extracted from the DAH. The Bay number map requires manual data entry to update as the DAP plate tables don’t convert to text very well.
The real question: Is a Threshold map required?
No matter how you add it to the menu, our vatsys menus are getting large and at risk of hiding the important components in clutter.
Overcrowding of menus is not something I had considered and fundamentally, no it's not required and may only be used by a small percentage of users. Being a ground map, the impact of another menu entry may be considered less.
While I'm not opposed to the idea of a community maps folder, there would need to be a way for us to verify the validity of the data with little overhead. I don't see this map as something that is exactly necessary, as the information can be easily added as a text field. In my opinion, a controller should know the runways of a field before they log on, so if they need this map that's a different issue.
Like Chris has mentioned, we shouldn't make it too easy for controllers to jump on a positions unprepared. In recent months, I, among others, have seen a serious decline in preparedness (controllers not doing basic study of LIs and airport layout) when controllers are logging on for the first few times. It would be best to encourage the use of the F9 label tool to label runways is absolutely necessary.
Data compiled from TCU maps.
Formatted through a few find & replaces (I haven't been able to write a script to do this yet).