SRMvACC vACS Profile#209
Conversation
SRMvACC Newly built profile for vACS.
|
Hi! As a start: let's not use dashed FIR-codes, please. If you're not managing the VC and VR datasets separately (by different people), I suggest either picking the "main" one (if that exists) or going with a more generic code, such as "SMR". |
MorpheusXAUT
left a comment
MorpheusXAUT
left a comment
There was a problem hiding this comment.
The "Checks" tab of this PR will always have a "CI" entry that'll automatically run validations against your dataset, telling you what's missing, incorrectly formatted, etc. It'll run for every change you push, but I currently need to manually approve it every time since this is your first time adding something to our dataset.
Make sure to check it out, I pulled most of the errors out there for now, but if you have an update, you can use it to check your changes, unless you want to use our local tools
| "prefixes": ["VCCG"], | ||
| "frequency": "118.075", | ||
| "facility_type": "TWR", | ||
| "profile_id": "VHHK" |
There was a problem hiding this comment.
Is this purposefully different than the others, or from copy/pasting? Sorry, not familiar with the airspace/stations, just checking for general plausibility
There was a problem hiding this comment.
Oh this is my sole mistake, I was replacing SRM one.
| "profile_id": "VHHK" | ||
| }, | ||
| { | ||
| "id": "ASEA_FSS", |
There was a problem hiding this comment.
You cannot/must not define stations or positions from other FIRs, even if you want to use them in your own profiles, etc.
Station and position IDs are globally unique across all of the vacs dataset.
ASEA_FSS is already defined in the VH dataset.
If it's a station or position that is shared between different FIRs, it still can only be defined once, and you'll need to agree with the other FIRs on where it's supposed to be defined. For this situation, I'd suggest keeping it in VH, since it's already there, unless this is completely wrong.
Same goes for AFRS_FSS.
ASEA_W_FSS is actually not defined yet, so it's fine to stay.
If you're missing a neighbours station/position (since they haven't done their dataset yet or simply haven't added it), don't define it yourself, rather leave it out until it has been added.
| { | ||
| "stations": [ | ||
| { | ||
| "id": "ASEA_FSS", |
There was a problem hiding this comment.
Same as in the positions - I would suggest remove ASEA_FSS and AFRS_FSS stations since they're already defined and you can use them in your profiles.
| { | ||
| "id": "VCCK_TWR", | ||
| "parent_id": "VCRI_APP", | ||
| "controlled_by": ["VCCK_TWR"] |
There was a problem hiding this comment.
You reference a VCCK_TWR position here, which does not exist. Every reference in the vacs dataset must exist - if it's not added yet, you'll also have to remove whatever references it.
Same for VRDA_TWR, VRMG_TWR, VRMK_TWR, VRNT_TWR.
Just for clarity, since I know it's a bit confusing:
parent_id references another station. It's used to "inherit" to coverage from its parent, so it will automatically get the parent's controlled_by list as well.
controlled_by references a position and defines the order in which positions are selected as the one currently covering a station. They do not inherit anything.
| }, | ||
| { | ||
| "id": "VCCH_TWR", | ||
| "prefixes": ["VCCG"], |
There was a problem hiding this comment.
| "prefixes": ["VCCG"], | |
| "prefixes": ["VCCH"], |
| "profile_id": "SRM" | ||
| }, | ||
| { | ||
| "id": "VOMM_CTR", |
There was a problem hiding this comment.
Same here - please don't define external stations or positions unless you can actively control them (e.g. shared between FIRs)
| }, | ||
| { | ||
| "id": "VCBI_TWR", | ||
| "parent_id": "VCBI_APP", |
There was a problem hiding this comment.
No station VCBI_APP exists
| }, | ||
| { | ||
| "id": "VCCA_TWR", | ||
| "parent_id": "VCCA_APP", |
There was a problem hiding this comment.
No station VCCA_APP exists
| }, | ||
| { | ||
| "id": "VCCK_TWR", | ||
| "parent_id": "VCRI_APP", |
There was a problem hiding this comment.
No station VCRI_APP exists. See comment below for the difference between parent_id (station) and controlled_by (position) - or the respective docs: https://github.com/vacs-project/vacs-data/blob/main/docs/dataset/stations.md#station-fields
| "controlled_by": ["FIMM_FSS", "AFRS_FSS"] | ||
| }, | ||
| { | ||
| "id": "YMMM_FSS", |
There was a problem hiding this comment.
External? If not: missing position
|
Furthermore @JAYWestFiveHenry Are you able to not define FIMM FSS, or any other VATSSA position as it prevents us from defining it on our side 🙂 |
Copied, I'll remove it |
|
I Just gonna Kindly let you guys know and clarification from us So we do this profile for SRMvACC covers VCCF (Colombo) and VRMF (Male) FIRs. we do have neighbours from our end. For our FSS Neigbours For our Internal FSS Positions I thought we just gonna copy our data that programmed from GNG Sector files. I didn't know the data it's differ from GNG Sector files. Indeed there's a lot of things to learn, I'll follow ur guys suggestions. I just gonna fix them when there's an error. if u need our Airspace Info from us. Let me know as well Kind Regards - Henry ACCSRM4 
|
3 participants
SRMvACC profile for vACS Dataset.
Dataset Changes
Thank you for your contribution to the
vacsdataset.Warning
Please make sure your dataset is in the correct
dataset/{FIR}/directory, otherwise it will not be picked up by our validations and release process.Hi and Good Day,
My name is Gia Huy Tran, you guys can call me Henry.
I'm currently as SRM Director of Maldives (ACCSRM4) from SRMvACC (Sri Lanka and Maldives).
vACC Website: https://4r-ipm.me/vaccsrm/about.html
VATWA HQ: https://hq.vatwa.net/vacc/SRM
This PR adds our SRMvACC's Current Positions, Stations and SRM Profile for our vACC.
Discord: reversers_normal
Email: [email protected]
NOTE: We're new to the Data Profile for vACS, I've read the manual on main dataset github, it's really difficult to understand the process. if there's anything to fix and updates. Let me know.
Kind Regards - Henry (ACCSRM4)