I just wanted to seek for some more summits in the neighbourhood, and I spotted the mapping doesnt work well. I thought it was my iPad, but it seems the same on PC with all browsers: i see nothing on the drop-down lists. I also realized the address changed (has it all been moved to another engine/server)?
Is there something wrong with the sotamaps now?
The mapping doesn’t work for me either, unknown association error. No associations are listed.
I’m a regular user and I can confirm it seems to have lost all the data. The pages are loading OK, just the association drop down is not working.
I am sure someone will be along in due course and put all the “mice back inside the machine” to make it all work again.
Of course, this kind of thing has to happen when I’m on holiday, doesn’t it? I’ve had a quick preliminary look at my db with the few tools at my disposal here in deepest Tuscany, and all the indications are that something has gone wrong with the regular importation of SOTA summits data. More info later, lashings of apologies all round…
Over the weekend SOTAwatch’s summit lists were lacking chaser data, so it also, presumably, suffered a slight data import hiccup. I guess it’s possible the mapping problem may be upstream from SOTAmaps, and may fix itself with the next download. Or not.
…and yes, systems have this way of working fine for months on end, and then picking the days you’ve gone away to go wrong in some interesting manner…
73, Rick M0LEP
Wonder if it’s the work Andy is doing on codepage/character sets…
He mentioned something about cloudy storage…
73, Rick M0LEP
Yes Gerald, it would appear so. I notice that the table in the SMP database holding the summits data has been corrupted. Now that is a first for me, after using and administering MySQL databases for nearly 20 years, I’ve never seen such a thing. The source of the data is Andy’s summits export file, which has many strange characters in it, especially in names of East European and Ukrainian summits.
Not sure what I can do from here, but I’ll play around until I find some kind of solution
A lot of my job is spent tying together seemingly unconnected events…
Good luck with that!
Remember you are on holiday and that we will all cope for a while without this very useful resource.
Yesterday sunday-morning (UTC) it was also not possible to use the mapping-tool. Before i started my activation i liked to make sure of my summit’s reference but i had to use the SOTA-goat on top of the summit. To find the summit via the “summit” Link was also working fine (if you know the summits name ;-))
There is a corrupted line in the export file, with summit reference VE9/YK`-001 (i.e. it has a spurious grave accent character in it). I spotted it on Saturday. Could this be the source of the problems?
Andy knows about it.
Saturday’s change did also introduce Cyrillic into the UT summit names, but there were plenty of “interesting” characters there before so I don’t think this is likely to have broken anything.
OK, I’ve now had a chance to better inspect the summits data csv file and I find that the encoding is UTF-8 OK. What’s not OK is that the csv format has changed, but I had received no indication that the format was going to be changed.
No problem - I need a little time to alter my import script to accommodate the new changes.
Working here without my own Win7 laptop, and with a Mac, with which I’m not totally familiar.
I don’t think it has… I’ve got “before” and “after” on file, and there is no format change that I can see. The file has been UTF-8 for ages. The actual characters present are now from a richer set, but this isn’t a format change.
Update: it’s not the format (by which I had meant the number and disposition of fields in each record), it’s the CSV column separators which have been changed. Sorry, it’s a little difficult to navigate between the various tools I have open here. I’ll email Andy, who’s probably reading all this with a bemused grin…
I just downloaded yet another copy - I don’t see a change. Delimiter was comma (as you would expect in CSV) and still is.
Are you sure it’s not that dodgy summit reference that is breaking things?
This is assuming that you download the same things as I do, of course.
Grinning? Not really, I’m just having some R&R in Edinburgh and when I’ve finished lunch andget back I’ll have look.
FYI, the bad record is line 30548 of today’s file.
Martyn - the SMP uses a special csv produced by Andy for our import - it’s this file which is causing us problems. And using the primitive set of tools at my disposal, I have no way of identifying line numbers. Ho hum.
Ah, OK, so in that case my observations about the public one probably aren’t a lot of use. Sorry about the red herring. But I thought it worth mentioning that there is a corrupted summit reference in the database as well as the character set changes.
Same for me. Not working while researching mountains in Wyoming.