Our updates for 1st July are now being uploaded by Andy.
This includes catch-up on some of last-month’s updates (VE7 update, JX launch), and some new ones.
We have our second association in Brazil - PR8 Maranhão. Welcome to AM Pedro, PR8ZX.
VE2 has a major update with some changed summits and new summits in the south. There’s still lots left to list in the north of course!
EA4 has the first stage of an update, moving a few summits and marking some for retirement. There are lots of new ones coming. Moises is working on names for these, and we’ll get them listed soon.
Just planning the next run to southern Scotland. By chance I found on Hill Bagging UK that GM/SS-257, Troweir Hill is no longer a Marilyn. When is this being removed and where can I find all this information please?
You are right that Troweir Hill GM/SS-257 is no longer a Marilyn. However this is currently still a SOTA summit as it hasn’t been removed from the SOTA programme yet. This will need to be removed at some-point along with some other SOTA summit deletions and additions in GM. The GM Association Manager Andy MM0FMF isn’t doing any of these changes until he manages to activate the GM SOTA that are no longer Marilyns himself.
Exactly, it’s called AM’s prerogative. I wanted to activate all the summits I’m most likely to do before deleting them. There are deletions and at least 1 new summit. There are also summits being deleted but their alternate tops being promoted so a new ref and one Munro where the summit moves within the AZ so no new ref.
We still have unactivated summits in GM, so there’s no rush in my opinion to push the changes yet, and I wanted them in my log. I’ll make sure there is plenty of notice, 3 months say, before any changes to give everyone a chance to activate/chase them.
I pushed a couple of changes to EA4 scores, EA4/CC-016 and EA4/GU-031 have new points values from 1-jul-2018.
Also W5O/WI-025 has been renumbered as W5O/OU-034. If you worked W5O/WI-025 in the past you will find it will have changed in your DB logs. You will now see W5O/OU-034 instead. The summit was moved to a different region after some cleanup of W5O and it looked out of place in the region it was in. This change got stuck on the list of changes but never actually made it to the DB.
The new Brazilian association "PR8 Brazil - Maranhão " was originally spelt as Maranhao. I fixed the missing diacritic mark and was happy. Unfortunately, this name is causing a problem in the transfer and backup of the AM reports. The problem is somewhere between a Windows based server running software written in C# on ASP.NET and .NET frameworks (some written by me), a Windows file zip utility and a Linux server running software written in Python (some written by me). The problem is encoding this character into a filename. It works on Linux or Windows. But getting it transferred is not working and the AM reports are not getting updated. It’s probably a simple fix but I’m about to go away for VHF field day and haven’t got time to fix it now. So, please accept my apologies for changing it back to Maranhao until I can update the software.
Well yes, these days we do expect Unicode characters to be OK in file names, even though it can cause trouble with things like case folding and sorting, which have to be done in the context of a specific language and cannot be done correctly by character code alone (case sensitive filesystems win here!)
But the application you cite here sounds like a machine to machine workflow, and for this it would seem to me to make more sense to use short stable encodings in the file names rather than a string intended for human display. In other words, I would use “PR8”. This won’t change even if spelling errors etc are corrected, and is pretty much guaranteed to be OK with the most restrictive filesystem likely to be encountered.
I’m fairly sure the 1st AM reports only used the code which is ASCII but it was extended later. It’s not a big job to change except when you are in a tent playing VHF contesting. The issue being zip has no proper way to express encodings so when you zip on Windows and unzip on Linux you may be in a world of pain. It works with La Reunion (which has an accute on the e) which leads you into a false sense of security.