The mapping feature is one of my favorite elements of SOTAdata3. In my brief experience before today it worked flawlessly, but something is quite weird about my activation of W6/CT-019 today. I apparently worked the North pole and a station in China that I wasn’t aware of. Pasting in some screen caps of the SOTAData map vs the SOTAMaps.org version.
Two people involved here: W1NV has a positive longitude, so he’s listed himself as being east of the meridian, not west of it, and KF7HP, who has transposed latitude and longitude and it’s pushed him off-world as a result.
SMP doesn’t use the user provided details from their profile, whereas SOTAData will use that by preference, assuming (sometimes wrongly) that people actually know where they live.
4 Likes
A small correction:
“SMP CANNOT use the user provided details from their profile” - since it has never been allowed access to such information. (Which is why the SMP activations page has a dialog to allow any user to input missing QTH positions, or to update faulty QTH positions, which are then saved to a SMP-owned DB)
“SOTAData will use that by preference” - since it has access to everything, and can choose which data to use.
2 Likes
Many thanks… I contacted them both with nice emails and they corrected their data. All fixed… Data quality, one user at a time 
73 and thanks for the speedy response.
3 Likes
It’s a good thing Tom! I can’t imagine the debauchery that would have ensued if my longitudinal data remained incorrect!! Haha. 
All kidding aside, thanks for the heads up. Not sure how that transpired.
2 Likes
Yet there we were Rob on 27th Jan 2014 discussing how we would create a clone of the main DB for you to directly access. That would give you direct access to a day old version of the data and we (SOTA) would be safe because your code would not be accessing the real DB but a backup. (Nobody gives some 3rd party direct access to their live database eve if it’s read only access.)
But, and I have the emails here, where you said “my provider does not, and will not, activate the MSSQL libraries in PHP for ANYBODY”. So rather than you go and find a webhost that would allow you to access an MSSQL DB, we looked at generating a MySQL copy but the SOTA hosts of the time did a poor job on their MySQL support.
But apparently that wasn’t good enough.
1 Like
So, the MT were adamant that the SMP should have no access to the live DB, but rather a clone of that DB. That’s a sensible decision from the security and data management standpoints - I had no issue with that at all. The reason I did not choose a webhost offering access to a MS SQL DB Server is that such hosts operate exclusively in a Windows environment, using the dreadful ISS as the web server. I prefer the Apache web server which runs almost exclusively on Linux machines. It’s simply a personal choice of servers, which has no bearing on the data themselves.
A clone of a database is a clone of the data in that database. It makes no difference at all whether the DB engine of the cloned data is MS SQL Server (an instance of which I administered and developed for several years in a professional capacity), or PostgreSQL, or DB2 (been there, poor DB management), or MySQL, etc. Data are data, and the various SQL flavours used by these engines to manage those data are similar enough that one can change from one engine to the other with relative ease. Been there, done that.
That would, to my mind, be a rather jaundiced way of looking at the situation, but we’re all entitled to our opinions.
EDIT: if I have any criticism of the data replication between the SOTA live DB and the SMP clone DB, it’s that the replication process is an incredibly complex thing to manage, and is prone to all sorts of problems, like servers crashing mid-process, to name but one. I’d personally hate to have to be responsible for maintaining such a system - thankfully, I was never involved in it.
Thanks as always for your insights.
Cheers, Rob
Another point - yes, the SMP WAS granted access, via the DB cloning process, to the greater part of the SOTA live DB. But the part of the SOTA live DB which included QTH positions was never included in the cloned data.Hence my statement that
The SMP had to source its’ own set of such data, which was pulled from several sources, including qrz.com.
1 Like
So let’s just be clear here Rob. We (SOTA) had a solution that was viable and working well for the 1000s of weekly users. You approached us and offered to write a map and then were unable to access the data we offered as the web host you had picked would not allow what you needed to do you tasks. We looked at alternative data sourcing but support on our host was not good. But hey, our host sold itself as a C#/ASP.NET/MSSQL hosting company.
The choice at this point is we (SOTA) find a new host that supports all the current requirements and ALSO what we need for you, not that easy as there are significantly fewer ASP.NET hosts in the world. Or you go and find one of the billion webhosts that either provide FreeTDS or the libraries you needed.
Put bluntly SOTA is the dog and your mapping project is the tail. The tail does not wag the dog.
You were offered access but chose not to make the changes needed to your side make use of what was on offer.
Are you saying that I was first offered access to the live SOTA DB, but that I rejected that offer because I didn’t like the Windows/MS SQL Server option? And that subsequently, the SOTA MT were forced down the road of offering a cloned DB of my choice? Is that what you’re saying?
Or are you saying that the decision was made right from the outset that the SMP would only be offered a clone of the DB (I believe this IS what you’re saying since, as you point out, it’s the most sensible option). If so, then it just comes down to which DB engine the cloned data would be held in - to this point, MySQL (my preferred DB choice) runs perfectly well in a Windows environment (as it does here on my dev machine), and costs nothing to install or manage. Not a difficult choice for anybody running a website on a C#/ASP.NET/MSSQL hosting company’s server, if the website owners have admin access to the server.
But the tail did not force the dog to adopt it - the dog could just as easily have said “Forget it, we’ll grow our own tail.”
There have always been some very able programmers, DB and IT experts in the MT who surely could have come up with their own SOTA mapping solution. For whatever reason, that didn’t happen, and one solitary outsider had the idea, and just enough knowledge and experience, to come up with a viable mapping solution - a solution which the MT at the time seemed to be delighted to adopt.
At least that’s my memory of the situation - I no longer have copies of any emails from that time. Tempus fugit, and all that…
OK guys, you can both stand down. No point rehashing the past. The replication process is crap - I know - but we’re where we’re at and we’ll get to where we need to be eventually. A reasonably large part of SMP no longer uses the rpelication, although we do still rely on it to get queries that cross the two DBs between SMP and the replication.
The user profile data is actually stored on the SSO server so it’s not even in the original DB for it to have been available to be shared, so any discussions that were had or choices made or not made are largely irrelevant to the discussion in any case, and didn’t need to be brought up, Andy.
4 Likes
I have a problem uploading a log in FLE format - it doens’t seem to be recognising 70cm as a band and it’s using the last band that has been recognised (2m in my case). When I load into the database it thinks 70CM is a call sign. Excerpt from the file below.
mysota gw/nw-043
70cm fm
1313 gw4bml/m 55 55
14 m7rtb 52 55
16 m0cqe 54 55
21 m1fhm
22 2e0jwa 59 53
2m fm
26 m3tmx/p g/sp-017
70cm fm
27 m3tmx/p g/sp-017 56 59
28 g6aek 55 51
mysota gw/nw-042
2m fm
1541 2w0jyn/p <POTA gw-0027> 56 59
70cm fm
42 m0xja
43 2e0jwa 55 33
45 m6yce 56 53
2m fm
47 2w0jfj/p gw/mw-038 52 54
70cm fm
53 mw7etj/m 55 55
I think it has been like this since day 0 - I’ve checked my previous FLE and any 70cm contacts have the same issue.
I have tried without success:
- Changing the first contact to 70cm
- Trying 433MHz instead of 70cm
- Trying 0.7m instead of 70cm
- Adding a blank line after the “70cm fm” line
This also affects 23cm, and possibly other sub-metre bands.
1 Like
Interesting as this morning I uploaded a mixed csv log and none of the chases or activations have appeared in the Honour Roll or my page on the database reports. Using the Manage Uploads button reveals an apparently successful upload.
73,
Rod
1 Like
I Jedi-mind-tricked the answer to this before I even opened up the database to check. In answer, I will ask, “What year is it, Rod?” 
1 Like
Yes, it has been a bug forever, and the fix should now be building. You might have got it to work using just a frequency - like 433.0 fm - but I’m scanning the code and guessing right now.
2 Likes
Oh dear! It seems to be 2024 for chasing and 2023 for activating - apologies. 
No extra activator points as we did the same hills last January.The system really did accept the logs correctly and I do seem to have activated the two hills just a couple of days apart. So all that is lacking is a bit of AI to detect dozy activators who don’t know what year it is 
Back to the Manage Uploads button - delete and try to get it right this time. 
Thanks for all the work on the system Andrew.
73,
Rod
EDIT - All done - looks OK.
4 Likes
That’s a feature I never thought I’d need but has come in very handy.
I have just re-uploaded the log and it is working fine now. Thanks for sorting.
Sorry if this has been raised already. And apologies for raising it here when it probably should be against sotawatch.
==
Just logged 3 chases from sotawatch3. The first 2 had the correct UTC date, but the 3rd (after rollover) shows the correct time but the wrong date (the previous day).
I’m guessing this is because the spot was posted the previous calendar day, but UTC rollover had occurred between the spot and my chase. Presumably thus a sotawatch bug, rather than the new db related?
1 Like
There’s legitimate reasons to choose either option so instead of changing the underlying logic, I’ve added the ability to edit the date and just pushed it live (after testing with a chase of VK3LE)
1 Like