ian/spothole
2
1
Fork 0
Code Issues 19 Pull requests Projects Releases 5 Packages Wiki Activity Actions

Plot stations according dx_aprs_ssid #68

New issue
Closed
opened 2025-10-28 15:11:26 +00:00 by W1CDN · 7 comments
W1CDN commented 2025-10-28 15:11:26 +00:00
Copy link

I don't think the map groups by SSID at the moment, but that would be helpful for packet or APRS.

For background, I'm working on caching locations locally before reporting them, but the caching is done per callsign-SSID combination. For packet, the SSID can mean physical location, but it can also mean services on a single station (e.g., -7 for node, -1 for BBS, etc.).

I don't think the map groups by SSID at the moment, but that would be helpful for packet or APRS. For background, I'm working on caching locations locally before reporting them, but the caching is done per callsign-SSID combination. For packet, the SSID can mean physical location, but it can also mean services on a single station (e.g., -7 for node, -1 for BBS, etc.).
ian commented 2025-10-28 20:58:48 +00:00
Owner
Copy link

Hi, I'm not 100% sure what you mean, so could you explain a bit more about what you're after compared to what the map does now? e.g. is the problem that you want data from spots with different SSIDs to be combined into one? Or that you have multiple spots in the same place on the map and it's not easy to see what's there? Or that the de-dupe function is too strict because it doesn't take into account SSIDs and will only return the latest spot of a callsign, regardless of SSID?

As a related thing, I didn't realise packet stations used SSIDs. Would it make sense to rename the field from dx_aprs_ssid to just dx_ssid?

Hi, I'm not 100% sure what you mean, so could you explain a bit more about what you're after compared to what the map does now? e.g. is the problem that you want data from spots with different SSIDs to be combined into one? Or that you have multiple spots in the same place on the map and it's not easy to see what's there? Or that the de-dupe function is too strict because it doesn't take into account SSIDs and will only return the latest spot of a callsign, regardless of SSID? As a related thing, I didn't realise packet stations used SSIDs. Would it make sense to rename the field from `dx_aprs_ssid` to just `dx_ssid`?
ian self-assigned this 2025-10-28 20:59:03 +00:00
W1CDN commented 2025-10-28 21:39:53 +00:00
Author
Copy link

This is the one I'm trying to say:

Or that the de-dupe function is too strict because it doesn't take into account SSIDs and will only return the latest spot of a callsign, regardless of SSID?

It's sort an edge case since I'm trying to avoid using the Internet to look up locations based on callsign. But if someone were to try to use this for APRS, the results would be similar.

Right now, the locations from all base callsigns are combined into one on the map. So what happens is

  • MYCALL-7 (packet station node) sends a beacon with an APRS location, which I parse and include in the API call
  • MYCALL-1 (packet station BBS) sends a MAIL beacon, but no location is included
  • The lack of location from MYCALL-1 overwrites the location for MYCALL (which was from MYCALL-7), and it disappears from the map.

The solution for the above situation is probably for me to cache locations based on MYCALL without the SSID. But there are also situations like

  • MYCALL-7 beacons a location and it's delivered to the API
  • MYCALL-15 (a mobile or temporary node in a different location) beacons a second location, which is also delivered
  • The location from MYCALL-15 overwrites the location for MYCALL, and now there is ambiguity about where the station (which is currently not identified by SSID in the UI) is.
This is the one I'm trying to say: > Or that the de-dupe function is too strict because it doesn't take into account SSIDs and will only return the latest spot of a callsign, regardless of SSID? It's sort an edge case since I'm trying to avoid using the Internet to look up locations based on callsign. But if someone were to try to use this for APRS, the results would be similar. Right now, the locations from all base callsigns are combined into one on the map. So what happens is - MYCALL-7 (packet station node) sends a beacon with an APRS location, which I parse and include in the API call - MYCALL-1 (packet station BBS) sends a MAIL beacon, but no location is included - The lack of location from MYCALL-1 overwrites the location for MYCALL (which was from MYCALL-7), and it disappears from the map. The solution for the above situation is probably for me to cache locations based on MYCALL without the SSID. But there are also situations like - MYCALL-7 beacons a location and it's delivered to the API - MYCALL-15 (a mobile or temporary node in a different location) beacons a second location, which is also delivered - The location from MYCALL-15 overwrites the location for MYCALL, and now there is ambiguity about where the station (which is currently not identified by SSID in the UI) is.
ian commented 2025-10-29 06:16:39 +00:00
Owner
Copy link

Got it. I will take SSIDs into account more widely in the software, including in the dedupe functions, and it should resolve this.

While I'm looking at this, how are you submitting spots with SSIDs at the moment? Are you setting dx_call to the base callsign and dx_aprs_ssid separately? If so do you prefer that, or would you rather submit the whole thing as dx_call?

Got it. I will take SSIDs into account more widely in the software, including in the dedupe functions, and it should resolve this. While I'm looking at this, how are you submitting spots with SSIDs at the moment? Are you setting dx_call to the base callsign and dx_aprs_ssid separately? If so do you prefer that, or would you rather submit the whole thing as dx_call?
W1CDN commented 2025-10-29 13:53:35 +00:00
Author
Copy link

As a related thing, I didn't realise packet stations used SSIDs. Would it make sense to rename the field from dx_aprs_ssid to just dx_ssid?

I think this makes sense in the long run.

While I'm looking at this, how are you submitting spots with SSIDs at the moment? Are you setting dx_call to the base callsign and dx_aprs_ssid separately? If so do you prefer that, or would you rather submit the whole thing as dx_call?

Until last night I was submitting the whole thing, but now I am submitting them separately because that seemed to make sense in the API schema. E.g., https://spothole.app/api/v1/spots?mode=PKT. But either way works.

>As a related thing, I didn't realise packet stations used SSIDs. Would it make sense to rename the field from dx_aprs_ssid to just dx_ssid? I think this makes sense in the long run. > While I'm looking at this, how are you submitting spots with SSIDs at the moment? Are you setting dx_call to the base callsign and dx_aprs_ssid separately? If so do you prefer that, or would you rather submit the whole thing as dx_call? Until last night I was submitting the whole thing, but now I am submitting them separately because that seemed to make sense in the API schema. E.g., https://spothole.app/api/v1/spots?mode=PKT. But either way works.
ian commented 2025-10-30 12:11:02 +00:00
Owner
Copy link

OK, the "dedupe" function now treats stations with the same callsign but different SSIDs as different things. SSIDs are now also shown in the various spot interfaces. dx_aprs_ssid has been renamed simply dx_ssid and there is also now a de_ssid field as well.

I'm not sure how close your map markers with different SSIDs are to each other, so try it out and see if you get a useful map. If you like I can also add the "Spiderfy" effect that Field Spotter has where if you have overlapping markers, you can click once to expand them a bit.

OK, the "dedupe" function now treats stations with the same callsign but different SSIDs as different things. SSIDs are now also shown in the various spot interfaces. `dx_aprs_ssid` has been renamed simply `dx_ssid` and there is also now a `de_ssid` field as well. I'm not sure how close your map markers with different SSIDs are to each other, so try it out and see if you get a useful map. If you like I can also add the "Spiderfy" effect that Field Spotter has where if you have overlapping markers, you can click once to expand them a bit.
W1CDN commented 2025-10-30 13:53:26 +00:00
Author
Copy link

Thanks Ian! I will test this today.

Thanks Ian! I will test this today.
W1CDN commented 2025-11-03 23:23:02 +00:00
Author
Copy link

Sorry for no update on this. I think the updates look great, I just need to adjust things in my end so I'm not sending empty SSIDs sometimes.

Closing, please reopen if you think there is more to do.

Sorry for no update on this. I think the updates look great, I just need to adjust things in my end so I'm not sending empty SSIDs sometimes. Closing, please reopen if you think there is more to do.
W1CDN closed this issue 2025-11-03 23:23:02 +00:00
ian added this to the 1.0 milestone 2025-11-09 07:28:41 +00:00
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
main
web_ui_options_faff
97-wwtota
88-colour-schemes
3-sse-endpoints
82-tota
73-hamqth-lookup
1.2
1.1.1
1.1
1.0.1
1.0
Labels
Clear labels   
blocked

   
bug

Something is not working

  
duplicate

This issue or pull request already exists

  
enhancement

New feature

  
help wanted

Need some help

  
invalid

Something is wrong

  
maybe

Not sure if I definitely want to implement this

  
question

More information is needed

  
wontfix

This won't be fixed

No labels
blocked
bug
duplicate
enhancement
help wanted
invalid
maybe
question
wontfix
Milestone
Clear milestone
No items
No milestone
1.0
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
ian
2 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ian/spothole#68
No description provided.