I was involved in a discussion in another forum comparing features of different scanners. In thinking of how I might accomplish certain things with the PSR-500, a new feature came to mind.
The idea is to allow an intermediate construct I'll call 'collections'. Collections would be scannable objects composed of lists of other scannable objects. As scannable objects, collections could be members of scan lists. It would be nice to allow collections to contain other collections, but this could lead to infinite recursion without proper checks when adding something to a collection. Probably best to limit collection members to being scannable objects other than collections.
This is primarily an organizational amenity, though there could be quite a bit of utility in being able to lock out collections.
There are any number of interesting possibilities that come up if collections are available. I live in the Orlando area where there are soon to be two major pubic service trunking systems servicing the city of Orlando, the county of Orange, and several additional municipalities in the area. Say I create collections for Orlando PD, Orlando FD, County Sheriff, County fire, city A PD, city A FD, etc. Now I can easily create scan lists for everything Orlando, everything county, everything city A, etc., plus have orthogonal scan lists for all police, all fire, all dog catchers, etc. So far this is nothing I couldn't already do. The big difference is that by locking out just a few collections I can quickly narrow these lists down to just Orlando PD or just county fire.
One example from the other forum was of a large industrial building fire. You might know from experience that the fire ground talk groups are often used in pairs. You create a collection composed of fire dispatch, fire command 1, and fire ground 1 and 2. You create another collection composed of fire dispatch, fire command 2, and fire ground 3 and 4. If a large building fire occurs you can quickly focus on just one of these collections and hear all the talk groups that will be concerned with this fire.
The basic idea is to provide an intermediate level of organization and also allow rapid reconfiguration for a specific incident you want to follow.
The idea is to allow an intermediate construct I'll call 'collections'. Collections would be scannable objects composed of lists of other scannable objects. As scannable objects, collections could be members of scan lists. It would be nice to allow collections to contain other collections, but this could lead to infinite recursion without proper checks when adding something to a collection. Probably best to limit collection members to being scannable objects other than collections.
This is primarily an organizational amenity, though there could be quite a bit of utility in being able to lock out collections.
There are any number of interesting possibilities that come up if collections are available. I live in the Orlando area where there are soon to be two major pubic service trunking systems servicing the city of Orlando, the county of Orange, and several additional municipalities in the area. Say I create collections for Orlando PD, Orlando FD, County Sheriff, County fire, city A PD, city A FD, etc. Now I can easily create scan lists for everything Orlando, everything county, everything city A, etc., plus have orthogonal scan lists for all police, all fire, all dog catchers, etc. So far this is nothing I couldn't already do. The big difference is that by locking out just a few collections I can quickly narrow these lists down to just Orlando PD or just county fire.
One example from the other forum was of a large industrial building fire. You might know from experience that the fire ground talk groups are often used in pairs. You create a collection composed of fire dispatch, fire command 1, and fire ground 1 and 2. You create another collection composed of fire dispatch, fire command 2, and fire ground 3 and 4. If a large building fire occurs you can quickly focus on just one of these collections and hear all the talk groups that will be concerned with this fire.
The basic idea is to provide an intermediate level of organization and also allow rapid reconfiguration for a specific incident you want to follow.