Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

add radio locator management features #598

Open
17 of 23 tasks
Tracked by #543
caver456 opened this issue Dec 4, 2022 · 5 comments · May be fixed by #599
Open
17 of 23 tasks
Tracked by #543

add radio locator management features #598

caver456 opened this issue Dec 4, 2022 · 5 comments · May be fixed by #599
Labels
enhancement Priority:High

Comments

@caver456
Copy link
Collaborator

caver456 commented Dec 4, 2022 •
edited
Loading

See #576 for the back story. Basically, SARTopo LocatorGroups are deprecated, will be going away at some point, and, for the past several CTD versions, they no longer provide left bar objects per radio.

Radiolog has been sending locator update requests to CTD since the early days, and should continue to send those same requests since they are used by Shared Locations. But, this is the first time that radiolog will need to interact with CTD enough to merit use of sartopo_python. (So it would make sense to use sartopo_python for the existing-style locator update requests also.)

Tasks:

  • pypi update for use in radiolog Dec. 2022 sartopo_python#46
  • connect to a CTD map
  • read from connected map: maybe the Radios folder and some radio markers already exist?
  • offer to automatically connect to latest map (and show name) at startup
  • sts link indicator light in options dialog
  • sts link indicator light in main GUI?
  • make a folder for all radio markers
  • if changeCallsign is needed, defer sending of marker until changeCallsign accept, or change label of existing marker (or delete it and add a new one) on changeCallsign accept
  • if sts is not yet created, queue radio markers and maybe show a one-time warning; process the queue as soon as sts is created
  • confirm smooth operation when CTD is killed after sts was opened
  • confirm smooth operation when map is deleted after sts was opened
  • confirm smooth operation if existing radio marker is deleted, then sent again
  • confirm smooth operation if entire Radios folder is deleted, then a radio marker is sent again [folder is recreated with no name, but can be edited; subsequent markers do go into that folder]
  • add a marker for the first call from a given radio
  • move the marker for subsequent calls from the radio
  • update the call time (in the 'Comments' field) on every call
  • change color to gray after a certain time?
@caver456 caver456 mentioned this issue Dec 4, 2022
Open
caver456 added a commit that referenced this issue Dec 5, 2022
@caver456
WIP #598
cc59e7c 
- first pass at options dialog entries (editingFinished in the map url field creates the sts
- first pass at marker addition and editing is working
@caver456 caver456 linked a pull request Dec 5, 2022 that will close this issue
WIP #598 #599
Open
@caver456
Copy link
Collaborator Author

caver456 commented Dec 5, 2022

Adding a task to update sartopo_python on pypi. The version on pypi right now doesn't let you specify whether you want to sync, or what the default timeout should be. We want to send all of these requests in the same fire-and-forget manner as the existing locator update requests, with timeout of 0.001 sec.

caver456 added a commit that referenced this issue Dec 5, 2022
@caver456
WIP #598
256dfca 
- first pass at radio marker queuing (while sts doesn't exist) is working
caver456 added a commit that referenced this issue Dec 6, 2022
@caver456
WIP #598
2d80876 
options dialog cleanup
caver456 added a commit that referenced this issue Dec 6, 2022
@caver456
WIP #598
1f3de45 
- improve options dialog sartopo fields callback logic: disconnect when checkboxes are unchecked, reconnect when checkboxes are rechecked if URL field is not blank; disconnect if URL field is blank
@caver456 caver456 mentioned this issue Dec 6, 2022
Open
19 tasks
caver456 added a commit that referenced this issue Dec 7, 2022
@caver456
WIP #598
e833020 
framework in place to modify label after CCD / on subsequent call; waiting for sartopo_python update
@caver456
Copy link
Collaborator Author

caver456 commented Dec 7, 2022

pausing work here for a while, to do prerequisite work on sartopo_python

@caver456 caver456 mentioned this issue Dec 7, 2022
Closed
25 tasks
@caver456
Copy link
Collaborator Author

First of several steps finished towards sartopo_python pypi update. See that linked issue above for details.

@caver456 caver456 mentioned this issue Dec 20, 2022
Closed
@caver456 caver456 mentioned this issue Jun 14, 2023
Closed
48 tasks
@caver456
Copy link
Collaborator Author

re-re-re-thinking - adding this issue back to the v4.0 roadmap, for a few specific reasons:

  • this task is significantly different than other sartopo integrations, for at least a few reasons:
    • doesn't attempt to modify assignment features
    • probably doesn't interfere with actions that any other IC personnel would take, so there's no need to address the topic of coordination / collaboration
  • it's still a major enough feature to merit a major version number bump

@caver456
Copy link
Collaborator Author

Notes from Steve:

The fleetsync interface in Caltopo uses the request, below, to place a marker on the map. A locator dialog within the Caltopo map sets up the group-deviceID (100-3050) and a name for the incoming message. When a new location comes in, Caltopo connects the points with a line. I assume that Caltopo does not expect several requestors to use the same group-deviceID at the same time (while the link is valid)?

So, the app would need to 'fill-in' the dialog for the desired map and then send the requests.

https://caltopo.com/api/v1/position/report/100?id=3050&lat=36.47375&lng=-118.85302

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement Priority:High
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

WIP #598 ncssar/radiolog
1 participant
@caver456