2026 Challenge Rules and Bugs

I have created this thread specifically for questions relating to the 2026 Challenge rules and also to report bugs in the Challenge software. We think we’re pretty well there with the bug fixes, but hey it’s software :wink:

Please only post questions regarding the rules, questions regarding scoring or possible bug reports. This is so we can more easily track problems. I’m terrible for causing thread wandering but please note carefully, any out of context or posts not about rules or bugs WILL BE DELETED.

You can continue general chat about the challenge or specific issues not related to rules or bugs in the existing 2026 SOTA Challenge (Part X) threads.

Thank you for your cooperation.

10 Likes

Hi Andy, thanks for this post. Is there a way to see the points off all regions?

How is the total score caculated? Whe I add up all the individual distances, I get a differetn value. Is it calculated internally with more precision than KM?

Thanks for your replay

73, Michael

Yes, the actual distance is calculated using Haversine method, then stored with 64-bit floating point precision.

No, this would put too much load on the database as it makes some calculations on the fly.

3 Likes

Several bugs in the underlying ADIF parsing were uncovered in collaboration with Peter @VK3ZPF through VK-Port-A-Log testing, which was impacting specifying WWFF and POTA location finding. These have been fixed, and in addition, using the <SIG>, <MY_SIG>, <SIG_INFO> and <MY_SIG_INFO> fields for ADIF are also now supported.

2 Likes

Whilst not exactly a bug, is there or will there be any kind of procedure to inform a chaser (I think it will only affect chasers) if their home/default location is set incorrectly which results in odd distance calculations.

I presume the chaser would need to update their lat/long in the update account menu on the database, but would the chases need to be deleted and re-entered to rescore or is that done on the fly when data is requested?

Whilst not competetive, it does distort the “friendly comparisons” and also would affect any points printed on their end of challenge certificates.

1 Like

I see that the chaser challenge score for KD7DUG seems excessive this early in the challenge at 87776 points. Might there have been a error in grid square entry?

Thanks, Etienne-K7ATN

1 Like

KD7DUG lat = -117.27716861737264, long = 33.285391909529515 :frowning:

Swapped them about and polished the chases. Much better now.

2 Likes

Yes, I see John M0XJA’s QSO with Gerald MW0WML on GW/NW-051 Foel Fenlli today clocked up a distance of over 7500km! I think his lat/long needs amendment!

1 Like

And yet in MW0WML’s log the distance is only 72km!
image

Because Gerald knows the difference between up/down and left/right :rofl:

Seriously, it’s easy to enter your lat/long back to front. I’m thinking about a way of pulling all the lat/long data from people’s registrations, and extent checking the figures against their home association to highlight all the suspect values. But there’s 350 days to do this.

1 Like

And there is a banner that shows on a person’s account if their lat/long is outside of their home association area, or is obviously wrong (latitude > |90|). The profile page now also has constraints on entry - you can’t enter a latitude > 90.

3 Likes

Presumably |latitude| > 90 in both cases. :wink:

Lat / Long is a really stupid standard. Where else do you have Y, X co-ordinates rather than X,Y?

Data entered backwards, it seems to me, is an inevitable result - and has been driving me nuts in the GIS field for years.

I tested an update to a commercial data-logging website widely used in NZ a handful of years back and found it had been storing lat / long reversed in it’s PostGIS database since it’s conception many years before. All good, apparently, as it also retrieved them reversed!

Until you reproject it, or dump the data and try and use it elsewhere, or want an accurate distance between points taking into account a realistic model of the actual shape on the earth.

1 Like

Preaching to the choir, as someone who has used PostGIS for many years. What’s really fun is the OGC extensions on the SOTA DB reverse convention on some PostGIS OGC functions!

But, the main reason it’s lat/long is simply because your average user cuts and pastes direct from Google Maps, and Google deliberately look at a standard and do the opposite.

The more you dig into it, of course, the more you realise that there is no standard, or rather 700 standards.

3 Likes

Latitude first has historical reasons. Until technology advanced to the point where accurate clocks could be made latitude could be determined by measurement at sea, but longitude could only be guessed, so positions were logged starting with what is known. By the time that accurate chronometers were invented this was so firmly established that it was beyond questioning.

The book ‘Longitude’ is an interesting read, if anyone is interested in the story of how Harrison solved the longitude problem.

1 Like

What is the reason for latitude/longitude in the profile instead of grid locator (maidenhead) ?

To work out your locator you need to know your lat & long.
To calculate bearings and distance between points on the Earth you need to know lat & long.

If you are not operating SSB/CW on VHF and up, knowing your 6 digit locator is not common.

1 Like

Spend twenty minutes dealing with ham-supplied data and you will learn to keep it as simple as possible. Everyone knows how to find out their latitude and longitude (even if some people don’t know which is which). You can cut and paste it from Google Maps. You learn about it in school. A GPS unit returns latitude and longitude.

Even the other thread(s) for the Challenge show a lot of people skeptical their chasers will know their locator.

That’s the reason why. It’s universal. It’s the least complex of many systems that exist.

4 Likes