Fixes #4853 - Remove Oxford (EGTK) holding point G

[rishab-alt]

Fixes #4853

Summary of changes

remove Holding point G

[PLM1995]

Please remove from the .kmz too

[rishab-alt]

Please remove from the .kmz too

DONE

[PLM1995]

Please remove from the .kmz too

DONE

Ta, but I think you've inadvertantly updated an outdated version. This is a general problem in my view that we're keeping loads of different .kmz files, so a tiny change like this needs a new file/filename.

I propose (in general - not just for EGTK):

• Going forward we have only one 'active' .kmz per SMR, named simply by the ICAO, e.g. EGTK.kmz which is updated for changes, rather than creating a new version each time minor changes/updates are made
• Any existing older 'version' ones get archived in a folder within the _data\SMR Files\EGxx folder, maybe like _data\SMR Files\EGTK\Old\
• If there is a major overhaul, like a redraw of the whole SMR, potentially consider archiving the older style, but not sure if this is necessary

Thoughts of others as ever welcome. @hazzas-99 et al

@rishab-alt Let's leave this PR as is for now until we have a definite plan how to handle the 5(!) Oxford .kmz files.

[AliceFord]

Please remove from the .kmz too

DONE

Ta, but I think you've inadvertantly updated an outdated version. This is a general problem in my view that we're keeping loads of different .kmz files, so a tiny change like this needs a new file/filename.

I propose (in general - not just for EGTK):

• Going forward we have only one 'active' .kmz per SMR, named simply by the ICAO, e.g. EGTK.kmz which is updated for changes, rather than creating a new version each time minor changes/updates are made
• Any existing older 'version' ones get archived in a folder within the _data\SMR Files\EGxx folder, maybe like _data\SMR Files\EGTK\Old\
• If there is a major overhaul, like a redraw of the whole SMR, potentially consider archiving the older style, but not sure if this is necessary

Thoughts of others as ever welcome. @hazzas-99 et al

@rishab-alt Let's leave this PR as is for now until we have a definite plan how to handle the 5(!) Oxford .kmz files.

If you're suggesting not creating new versions of the .kmz unless we're making a big change (which I think you are), sounds good to me! We'd just have to be careful archiving 'old' versions as in some SMRs it seems the newest version isn't just called EGxx SMR, instead it's one with the airac.

[PLM1995]

We'd just have to be careful archiving 'old' versions as in some SMRs it seems the newest version isn't just called EGxx SMR, instead it's one with the airac.

Yes, should (hopefully) be fairly obvisous from the last edit date - assuming the correct one was the last editted one.

[AliceFord]

We'd just have to be careful archiving 'old' versions as in some SMRs it seems the newest version isn't just called EGxx SMR, instead it's one with the airac.

Yes, should (hopefully) be fairly obvisous from the last edit date - assuming the correct one was the last editted one.

Mine are all dated at when I first cloned the repo D: (same for all other SMRs too)

[PLM1995]

Mine are all dated at when I first cloned the repo D: (same for all other SMRs too)

Your local files might do that yeah, but https://github.com/VATSIM-UK/UK-Sector-File/tree/main/_data/SMR%20Files/EGLL for example will show the last commit dates to the actual repo, so yeah we'll have to be careful but it's not impossible :)

[hazzas-99]

I'm very far removed from SMRs, haven't updated one in years. It struck me as a little odd that we were storing more than one kmz though? Surely if we need to revert to previous we can just access/download a previous version attached to a commit in the history? @PLM1995 @AliceFord

[PLM1995]

I'm very far removed from SMRs, haven't updated one in years. It struck me as a little odd that we were storing more than one kmz though? Surely if we need to revert to previous we can just access/download a previous version attached to a commit in the history? @PLM1995 @AliceFord

Yeah, exactly @hazzas-99. Seems easier to have one file we update than lots which don't track the changes well.

For this PR, it's probably easier for me to mess with the .kmz files myself @rishab-alt as explaining it would be beyond me and it isn't really directly related to this issue. I'll open a separate issue to standardise the others, but not start work on that until we have no open PRs editting .kmz files or we'll get conflicts when we try to merge.

@AliceFord would you like to document our policy on the wiki (I know how much you love the wiki) - feel free to run your changes by me first on discord.

[PLM1995]

Having to approve this myself as had previously requested changes, happy I did it right @AliceFord? @rishab-alt

[AliceFord]

All good 👍

[PLM1995]

How didn't I spot these first time I don't know - No need for the blank lines