vatSys / australia-dataset

7 stars 14 forks source link

PNG data #39

Closed zachbf closed 1 year ago

zachbf commented 1 year ago

PNG data (radars), positions, sid/star to be included in the AUS dataset for events.

psvatpac commented 1 year ago

Zach, I'd appreciate some more background on the purpose of including PNG as part of the OZ and Pacific datasets. Is it just having the radars available for coverage when controlling ARA, or is there a desire to have the ability to extend from ARA into AYPM?

Updating positions, sectors, volumes and radar is fairly straight forward but there are too many other files to update/maintain this manually on the OZ dataset (airpsace.xml, all the maps (sectors, airports, navaids, routes etc)) and I haven't looked into what code and DB changes may be required to do this.

Should we be considering a single dataset for all VATPAC airspace? - would need another level added to the vatSys maps menu though

zachbf commented 1 year ago

Hey Pete. I'm not sure whether the best answer is to do one dataset or not. Maybe? Needs more in depth discussion about any negative impact.

Reason for this though. During WF, I'm trying to give STAR clearances on ARA for PNG, and they aren't in the au dataset. I also had none of the PNG radars, so for me the tags were squares and for josh on AYPM, they were radar tracks.

how many sub menus can we define in the positions list? could we have something like AU_ENR -> Inverell (INL) and PAC_ENR->Moresby, AU_TCU -> Sydney etc?

psvatpac commented 1 year ago

how many sub menus can we define in the positions list?

Positions list is OK, as is the ground window list, could group under Pacific It's the Maps menu list that currently only allows two levels - those ,xmls in the maps root folder and the folder names within the maps folder that contain .xml files. So having a single dataset would mean all the airport folders would appear as items in the Maps menu - adding an extra 10 to the OZ 44 items

I just thought of a solution to this - group the .xmls in the maps root folder into folders Airspace and Navaids as in the NZ dataset, this will save 16 entries (airpsace and navaids containing 18 entries), leaving a single dataset with a total of 38, less than the current OZ maps menu. COAST_ALL could be added the the _Airpsace folder as well. Ashampoo_Snap_Wednesday, 16 November 2022_09h21m18s_001_ Ashampoo_Snap_Wednesday, 16 November 2022_09h21m24s_002_ Ashampoo_Snap_Wednesday, 16 November 2022_09h21m29s_003_

We can add PNG, FJ, NC etc to the beginning of the file names to keep the Pacific locations next to each other in the list, or just leave them as shown

Whilst this still needs code changes, it will be easier than coding to selectively add part of Pacific to OZ and retain it in the Pacific dataset as well.

psvatpac commented 1 year ago

Reason for this though. During WF, I'm trying to give STAR clearances on ARA for PNG, and they aren't in the au dataset. I also had none of the PNG radars,

I think the quick way to fix this is to create airspace.xml so it includes OZ and Pacific data and to manually update the OZ Radars.xml with PNG radar and adsd sites. You could even add all Pacific sites to radars.xml in case of an event into New Caledonia

zachbf commented 1 year ago

@zkgell what are your thoughts on having 1 profile for vatpac (call it AusPac) or something, removing the seperate pacific pack and including it all in one?

Z

codepip55 commented 1 year ago

If it's decided that we do do this, it will take a few AIRACs to get everything merged and compatible with SFG.

zkgell commented 1 year ago

While I agree we should look at including maybe PNG and Nadi FSS navdata in the Australia data set. I think that the Australia and Pacific Data sets should remain separate. Not only just for the sake of avoiding fixing something that isn't broke but, as we know, we have limited information on airfields and procedures in our pacific dataset whereas in Australia we are much, much, much more fortunate. The physical changing of profiles prompts controllers to view the two areas as different parts of our coverage