I am still getting direct messages from people on this so for the benefit of those who haven’t yet seen the comments in previous threads:
SOTAwatch3 now shares a login with the new Database site, the Mapping site and the new Summits site. SO, when moving across to SOTAwatch3, please use your SOTA Database login credentials.
However, there were some user records that didn’t properly get transfered to the SSO Server a few months ago. If you find that your database username and password doesn’t work, then please get in touch and we’ll fix you up!
For absolutely clarity, the username and password you used for SOTAwatch2 will no longer be used.
Also, the username and password you used for the SOTA Website will no longer be needed now the summit pages are served from the new Summits site. However, you will need to re-enter your latitude and longitude details by clicking your user in the top right and clicking Update Account in SOTAwatch or the Summits site for the distance and bearings to work.
One quibble, I wanted to look at the photo bank and was asked to sign into my Yahoo account. Yes I have one and would like to strangle it for the trouble it has given me. Is there any thought that it might be migrated to a friendlier access?
The only thing I did have in mind once things have settled down is to add photos to the type of resource that can be uploaded to the summits pages. These would then be displayed as a gallery on the summit page but also available elsewhere on association/region lists to brighten things up a bit.
I just entered data for 15 alerts for an August trip using Sotawatch3. Everything looks to be in order except for the summit point values seen when mousing over the alerts for 4 of the activations.
The alerts with the incorrect point values were for W0D/BB-012 (listed as 2 points, should be 8 points), W0D/BB-002 (listed as 4, should be 10), W0D/BB-001 (listed as 4, should be 10) and W0D/NW-002 (listed as 4, should be 10). The 11 correct alerts included summits in the W0D/BB and W0D/NW regions.
The scoring scheme has the capability to support different scores for summits. In some cases we got the points bands wrong, say too many 10pt summits or not enough 10pt summits. Any summit has a score and a date range when the summit is worth that score. In the case W0D/BB-012 I think the change in value came when W0D was split from one W0 association into W0C and W0D etc. If you look at the database history for the summit SOTA Database you’ll see the points changes with time.
From
To
Score
Bonus
08/Jan/2011
31/Jul/2011
2
3 points between 1 December and 31 March
01/Aug/2011
30/Nov/2016
8
3 points between 1 November and 31 March
01/Dec/2016
31/Dec/2099
8
3 points between 1 December and 31 March
At present SW3 is only looking at the 1st value found, 2 when it is now 8. It’s a known bug that will be fixed eventually.
Ok, this had me rather confused since when I added an alert for the same summit (W0D/BB-012) it came up correctly as 8 points. However, it was on editing the alert that the points reverted to 2 points. I’ll fix this.
In my original post I neglected to say that I had edited all of the alerts (changing one frequency). I am guessing that the W0D summits that showed correct point values following my editing were not on the old W0C summit list.
assuming, hypothetically, something happened to the weather and we needed to contract (or hypothetically, expand) the bonus season. Does the seasonal bonus attribute also have an effective date range?
Well, each region has an associated start and end for the seasonal bonus that’s checked when an activation is uploaded. Maximum of 4 months IIRC, and can be for either summer or winter (or, eg, monsoon season).
I understand that. But that’s not the same thing as what I was envisaging. That set of dates is based on a design that does not cater for the effective dates ever changing. Yet it needs to.
If there is a region with the start date of winter bonus at 15/6 and we change it to 1/7 with effect from 1/7/2019, only the activations later than 1/7/2019 that fall in the period 14/6 to 30/6 (ie. later years) should be affected. But if there is only one set of applicable dates as distinct from effective dates, then if it is changed, all activations over all time in that region would be affected by that change. A corresponding logic applies to the end dates.
So in the event that winter bonus effective dates are changed, it needs an extra set of effective dates to control it while not affecting awards in the past. It means that instead of those dates being in the region table, they have to be in a “bonus points dates” table, which would state the effective period of a particular set of bonus points start and end dates. It sounds like it does not exist as a separate entity in the DB.
If we had that entity in the DB, whenever we want to know what the start date of the bonus period is, we would look up the region code, combine it with today’s date and find the bonus start date that applies to today’s date. It might not necessarily be the same as the start of the bonus period last year.
Yes it does. You can have about 1million non-overlapping date ranges per summit. The most I have seen so far is about 3. I think we have future expansion room.
That’s what happens. Dates ranges grow and the scroing code knows when the QSO was so it knows wihch points to use.
Nope there’s lot of dates so this doesn’t happen. It wa design with that in mind.
Which is what we have.
Well you could look up the summit and the entire points history include the changing scores and bonus dates. It’s all there for people to see. When you set an alert you are setting for the future, you want the latest score to appear as you can’t set an alert back in time.
Is there any thought that it might be migrated to a friendlier access?