I’ve noticed an odd situation a few times. I often use the web-based SOTAWatch to monitor spots while sitting in my office at work, and if something interesting pops up I’ll go out to my car to try to work them from my mobile. While I’m out in the car, I use the Andriod “SOTA Spotter” app to continue to monitor the flow of spots.
On occasion I see conflicting spot information. Below is an example that I saw this morning - in my office at 1627, I saw a spot on SOTAWatch for AC1Z (newly minted MG!) on 14.345 SSB. I ran out to the car and fired up my rig on that frequency. While out there I pulled up the SOTA Spotter app and saw a spot for AC1Z at 1627 on 14.062 CW.
Obviously not a big deal, it’s easy enough to check both, but it seems that there must be something inconsistent about how the spots are being reported? (Note that at 1649, AC1Z was spotted on both systems on 14.062 CW).
SOTAwatch is correct by definition. But that doesn’t help you
I think you are seeing the results of the spots being edited. Only the edited spot remains on SOTAwatch and the time doesn’t update if the spot is edited.
The SOTA cluster doesn’t see edits and this is what was spotted:
DX de AC1Z 14062.0 AC1Z W1/HA-120 1627Z
DX de AC1Z 14345.0 AC1Z W1/HA-120 1639Z
DX de AC1Z 14062.0 AC1Z W1/HA-120 1649Z
SOTAwatch shows the results after edits but with no time change till a new spot is posted.
Tue 16:27 AC1Z on W1/HA-120 14.345 ssb (Posted by AC1Z)
Tue 16:49 AC1Z on W1/HA-120 14.062 cw (Posted by AC1Z)
I can imagine that applications might wish to be able to tell the difference between an actual new spot and an old one edited. Discarding information is rarely helpful.
The new API doesn’t see any deletions. It reports all the spots that are posted.
SOTAwatch app shows spots posted and it allows you to edit & delete what is on its display. It doesn’t mark any spots as deleted. It (politely) posts a new spot when someone edits an existing spot with the results of the edit.
Do we need to know a spot has been edited? Or is the new spot that reflects the edit enough for other displays? I don’t know. Do we need to know a spot has been deleted? Again I don’t know but probably we do.
The new API produces JSON encoded data and probably we need a field in there that says a spot has been deleted. That way all the data is there but there are useful hints as to how it should be interpreted.
My model would be that a user of the API ought to be able to reproduce what is displayed on the primary website. If it can’t, it’s a second class customer.
One obvious way to achieve this is to require the primary display interface to use the API. Then you can’t cheat.
Assuming the edited spot has a newer time than the original, I’d figure there’s probably no need to differentiate between a spot generated from scratch or a spot generated as the result of an edit, but…
yes, knowing that a particular spot has passed its use-by date could be useful information. Much the same effect might be achieved through something like a “QRT” spot, again assuming that such a spot would have a later timestamp than the previous ones, and applications always assume th emost recent spot is the one that applies.
Of course, things get a bit more complicated when it’s details like callsign or summit reference that get edited, because then, in the absence of an audit trail, it could be impossible to guess which spot had changed, and the old and new versions could co-exist.
As it currently stands, the API users get more information than the existing SOTAwatch, so the existing SOTAwatch is technically the second class customer.
Which it will. It’s almost like we know what we’re doing!
