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)?
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…
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.
Rob
Not sure what I can do from here, but I’ll play around until I find some kind of solution
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 ;-))
73 Peter/HB9CMI
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.
Rob
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…
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.