[BUG] RBN should query spot/cluster caches before querying qrz for location

[alanhargreaves]

Describe the Bug

I just went to check the RBN as I had VK2IO/P operating from a WWF Park (spotted for WWFF on spot line), but the display of the RBN went directly to QRZ and showed the location of his QTH rather than the spot.

To Reproduce

FInd CW operator who has a spot out (any spot) and ch

Expected Behavior

Before looking up QRZ dot COM, the RBN code should query the spot, and dx cluster caches for this callsign and band/frequency.

Screenshots

The inverted triangle is his 160m CW spot from VKFF-1318. RBN is showing his home QTH at QF56ob

Additional Context

Add any other context about the problem here. Include your callsign if you're comfortable sharing it!

---

73!

[alanhargreaves]

It looks like it is "supposed to", but it didn't for this case. I'm wondering if the "/P" caused any lookup issues.

[alanhargreaves]

We should be using encodeURIComponent() when using /api/rbn/location/:callsign in src/plugins/layers/useRBN.js, but this doesn't fix things.

It looks like server/routes/rbn.js relies only on the lat/lon we get back from the RBN servers, which appears to simply do a QRZ.com lookup.

I would think that if we have any of the following which are a match for callsign/band(and/or frequency) we should override the location for the RBN layer with the most recent of.

• dx cluster cache location
• activator spot location

It's been a while since I looked at location caching, but if we don't have any centralised caching (or at least a method of looking at all of the caches), perhaps we should.

[alanhargreaves]

ACTually no, that's not right, we hit the `/api/callsign/:callsign, so it very well could be that because we didn't properly encode the callsign from the client that we looked up the base callsign.

I'm running my local with this change now and "we shall see".

[alanhargreaves]

ok it looks like /api/callsign does not check our caches. It probably should.

[alanhargreaves]

.., and it's actually a little more complex than this.

When we query /api/callsign/:callsign, we really are after the orz or hamqth information. What we need is for the run code to then go and see if we have a better location for this callsign, WITH any prefix/suffix. We need something that will look at all of the spot caches for this callsign (and band) and if it exists, we use it for the location of the target callsign. Probably also ought to require the mode.

This calls for an api in the client that will do all of the lookups in one place, either by maintaining it's own cache (which will have its own problems), or by querying a number of "spot" lists.

i.e.

• potaSpots
• wwffSpots
• sotaSpots
• wwbotaSpots
• dxPaths

I was thinking of making this more generic, but for simplicities sake I'm going to implement it within the client run code and limit the functionality for CW RBN. A more generic version allowing for the addition of filters to use would be great, but I fear a lot more work and I'm not (currently) seeing what else might want to use the lookup.