Since February 1st, four regions of the former French “F” SOTA association have been grouped into a new “FL” (France Low) association.
These regions have only low summits compared to the mountainous regions of France. Having them using the same “points banding” as the Alps, for example, caused most of the French summits to have lower points than comparable summits in other associations.
The new French Association Manager, F5HTR, together with his efficient team, reviewed more than 3.000 summits, and made several hundreds of improvements to the summits data. Some summits were removed, others were added.
The result of this huge work is that France becomes now much more attractive for SOTA activators.
Congratulations to all contributors to this major effort.
Why are the summit points in FL/VO and FL/VO scored differently to the summits in FL/NO and FL/SO. The FL/NO and FL/SO region have all their summits scored as 1 pointers which the highest in FL/NO being 521m and the highest in FL/SO being 356m whereas in FL/VL summits from 350m to 500m are 2 point and from 4 point from 500m to 600m and likewise for FL/VO except for summits from 300m to 500m being 2 pointers. Surely, the point scoring system should be the same for all summit in the FL association.
Has the ARM been updated yet? I am interested in checking out the point banding for various regions.
Is it usual to have different point bandings for various regions within the same country? I am aware of different point bandings for different countries but I did not know it existed within the same country.
Finally, I am sorry that I have to ask this, but are the points supposed to reflect a level of difficulty to reach the summit or a tool to make summits more attractive for activators? I’ll dig more into the SOTA articles of organization to understand this a bit better.
Splitting an association and changing the points values has some interesting consequences.
I observe that history has been partially rewritten in that I have chases of FL/ summits now recorded. I presume this was done to avoid giving spurious uniques. However as far as I can see the new points values have not applied retrospectively. That is fair enough, but it makes it difficult for me to calculate my own score based on downloadable data. The changed summits have disappeared from the downloadable summit list, which means that the information about the original score has been lost. Is it downloadable from anywhere else?
If I retrospectively edit my log to change F/ to FL/ where appropriate, I will calculate my score wrong. If I don’t, I risk calculating my uniques wrong. Very messy…
I note that I have gained an association for Mountain Hunter, as it so happens that I have at least 2 chases in both F/ and FL/. But equally it would be possible to lose the qualification status of F/ if you ended up with one chase in each. This could make a Mountain Hunter previously awarded now show as not attained.
It’s worse than that. The historical scores for what are now FL are probably wrong at present. They should be correct soon. Correct in this case means old value up to 1/2/2017, new value after. I may rewrite history and make them the new bigger value back in time. I don’t know yet. This points error arose because of a “send three and fourpence, we’re going to a dance” comms failure.
Yes, it changes the past. Yes, some people may have fewer chases in a specific region that changes the status of some awards. But we wont be removing awards, they were issue against valid data at the time. As for uniques, you should not have lost or gained any. The summit reference may have changed from F/VO-001 to FL/VO-001 and the points may have changed. But the database knows that it is the same summit it always was.
Splitting was done to better accommodate the French geography. It’s nigh on impossible to get a decent points banding when you have some lovely wee summits and Mont Blanc in the same country. The split allows better banding for the places with plenty of lower summits. At the same time of the split there has been some determined validation of that the summits were really the right prominence and these summits have been deleted. New summits have been found and added. I’m not sure of the overall change in numbers at this point.
Splitting will throw up corner-cases. Deleting all the summits from one association and creating new summits creates bogus uniques. If you have climbed up F/VO-001 you have climbed it whether its reference changes or not. Swings and roundabouts I think between bogus uniques or some issues on displaying awards.
There is no bulk way to collect the old values for points as the summits list shows today’s values. However, every summit is in the database still, basically so you can submit a log for a QSO in 2005 say for someone on a summit deleted in 2008. You can use the find summit feature to show every summit there has ever been and if the score has changed you should see the a table showing the score for various dates.
I should say that I try to mail yourself and Rob DM1CM when there are new associations coming so you get a heads up in case it breaks your code for the gpx files you make available or Rob’s web site but it was missed off my list this time.
I’ll have a think about making a version of the summits list available including all the points.
Personally I would like to see the underlying tables delivered in a normalised form, along with some queries to generate commonly needed simple lists.
Have you considered SQLite as a delivery format? It can encode a complete database with multiple tables and queries in a single portable file. SQLite is widely used in apps to hold structured information, and it has none of the hazards of CSV.
CSV (comma separated values) however is a format that all can understand and use with any of the common spreadsheet programs - SQLlite is not. So for feeding applications SOTALite format may be OK however for data exports to users, I would say CSV is the best option.
Gerald, I can alert and spot one of the new summits.
Hovering on the summit ref in the alert says “summit not recognised” and the spot says “La Muraille”. I don’t why the alert page doesn’t know the summit name because the spot page does know the name.
Clicking the summit ref takes you to the SOTA website info page on the summit whether you use the alerts or spot page. It’s probably just something still to work through the caches. If it is not sorted tomorrow evening (Dimanche) remind me and I’ll ask Jon to look at it.
Absolutely true. But the problem for the current purpose (coping with summits with time-dependent points values) is that a single file can only contain a single table, which means denormalising the structure even more than it already is.
I’m sure the current CSV file will have to remain for ever for compatibility, but for advanced users I think a SQLite database would be a pretty good format.
I have finally had a moment to investigate how bad or good the historical points data is. Only FL/VO and FL/VL historical scores were affected and I have fixed this data.
Your scores are calculated when you enter either a chase or activation and saved for you separate from this data. So these summits having the wrong scores for chases/activations before 1-feb-2017 should not have affected anyone. Anyway, the scores should be correct both for the past, future and present.
The problem is occurring in the SOTAwatch web site and how it interacts with DB and its cache of data. The site is really running on its last legs and the effort to fix this is considered wasteful when Jon, the maintainer, has very limited time to spend on SOTA work currently due to his day job taking so much time. Jon said he will try and get the new SOTAwatch site active as soon as possible which should fix these kinds of problems.
This means that when you hover on a summit on SOTAwatch spots or alerts, you may not get accurate name or points info for the summit. But if you click the link, you get taken to the “new” SOTA website where the correct data is displayed. Or you can look on the database.