Some ZL3 summits mis-placed

Andrew, it’s nice to hear from you, and what you have to say about the workflow in getting the data to the user is interesting, and it’s especially gratifying to know that the process has been so well optimized. This is as it should be.

My particular beef - and the reason I use the ironic term “interesting times” - is with the time-delay in presenting corrections to mistakes in the data to the user. To my mind, the user - the customer if you will - is the most important part of this particular equation and, if I were administering such a system, I would take steps to ensure that the user is served with the corrected data ASAP. Which would mean that, for such cases as this one, the workflow should include an extra step to get the data changed in the database as soon as is practicable, so that the user can have timely access to the corrected data, even though the changes may not yet have been made to the background working documents.

It would seem, however, that the current SOTA ethos is to get the documents in order first, and the customers will just have to wait until the changes have percolated through an inflexible system (it’s two days later, and we users are still waiting for the corrected data). IMHO, that should change, but the professionals in the MT might well have a different take on the matter.

Lastly, I’m not at all suggesting that the MT should be perfect - we all make mistakes; it’s par for the course, since we’re involved in creating and maintaining complex systems. Even the inexpertly-written SMP (which somehow manages to stagger its’ way into the user’s browser) has at least some degree of complexity - no doubt the planned replacement for the SMP will be written professionally from the ground up…

Well, that’s part of the changes coming. At the moment, changes can only be practically pushed by one or two individuals, which is a bus-accident-worthy situation that no one wants. The delay is due to the fact one of those is chronically busy with his work and currently overseas with it (not me), and the other took a holiday to play SOTA (crazy that these MT types want to actually play SOTA occasionally :smiley: ).

It’s not so much that we wait for the documents to be in order, but that the step of synchronisation between the two canonical sources of information presented to the a) the SOTA customer (I use a similar viewpoint) in the SOTA DB and b) the AMs running updates that may include not-yet-approved summits, etc (in Sheets). is still a manual process. It’s an area we’re putting a lot of focus on and was discussed at the recent MT meeting. The Matrix principle: “Never send a human to do a machine’s job”. Change is coming, but it’ll depend on us finding time, as always. Hopefully when it happens, everyone will do a Keanu and casually say, “Whoa!”

I’m still alive, though it doesn’t always feel that way :smiley:

I did drop you an email around December chasing a next steps update on the other thing we’re working on; I didn’t get a response, and since then it feels like I’ve spent about 30 seconds in my home country so I’ve been very remiss in following it up. I know we’ve had issues with emails being dropped before, so I’ll drop a line via PM in the reflector later today to discuss; I know I’ve still got one or two outstanding actions on me. There was another suggestion that came in recently and I think the SMP project would be the logical place to put it.

Cheers,
Andrew

Î note that the changes have today propagated through to the database - however, one record has still not yet been altered: SOTA Summits . Perhaps an oversight?

Rob

No, it’s still to be done along with an AM change.

Well, I’m looking in the SOTA Summits page, where the lat/longs are given as:

Latitude: 172.2721 , Longitude: -42.6678 .

Which suggests to me that the db record has still not been changed, unless of course that page is static and not fed on the fly from the db.

EDIT: Oh, I’ve just seen the “it’s still to be done…” OK thanks.

This error bugged me. The files for uploading get fed through a variety of check processes during development and before uploading. Checks such as if there is a bonus that all the bonus data is present (i.e. bonus height, start stop dates etc.) So the code checked there was data though it didn’t check for sensible values, though it does now.

But the bad latitude value was nagging. Anyway it’s a classic case of not knowing all of what a library routine does. Lat&long are stored as reals and when the file is being checked, C# Double.TryParse() routine is called to ensure the number is a valid format real. For F/CR-265 it passed even though the value read was “41,511”. I’ve been digging in the docs for C#'s libraries and a comma is a valid grouping specifier for locale selected. The library reads that as 41, 511 i.e forty one thousand five hundred and eleven. I was taught to write numbers with commas for grouping thousands, millions etc. at school a long time ago. I think there is an ISO standard that uses spaces i.e. “41 511” as some European mainland countries use a comma where the UK and US use a period.

So here was some code that was trying to validate the data being passed a valid number and interpreting it correctly although not what was wanted. And I think that was the first one of these in some 70000+ summits I’ve seen uploaded. Now to find something that is a better verifier for numbers and preferably exists in the library so I don’t have to write it.

And such a function exists… simply a case of specifying exactly what we want to allow, decimal point and leading sign should do it. The default for any number is AllowTrailingWhite, AllowLeadingSign, AllowTrailingSign, AllowDecimalPoint, and AllowThousands which lets malformed numbers through.

style = NumberStyles.AllowDecimalPoint | NumberStyles.AllowLeadingSign;
culture = CultureInfo.CreateSpecificCulture("en-GB");
if (Double.TryParse(value, style, culture, out number))