Location-Based Scanning: Circles vs. Squares....

[Dave_D]

Hi all,

Does anyone agree that location-based scanning would be improved if scanners permitted polygonal definition of scanning areas? By this, I mean that the location of a programmed system would be defined by its corners, a multitude of lat/long points, rather than the popular point/radius method.

BENEFITS

1. Accuracy of location boundaries (e.g., counties) is drastically improved
2. Description of over-sized or awkwardly-shaped counties is simplified
3. Reduces or elliminates overlapping among neighboring, conflicting system areas
4. Locations of radio towers need not be known
5. Reception areas can factor geographic features (e.g., mountains)
6. A single location can accomodate one or more simulcast sites
7. With more accurate location boundaries, scanner users would receive fewer unwanted signals from neighboring locations.
8. Resolves problem of duplicating entire system programs to describe location by two or more points.
9. Supports areas of unlimited size; locations need not be limited to arbitrary radii.

CONS

1. CPU overhead required to track position among polygonal areas is greater
2. At first blush, programming 3+ points would appear to require more effort from scanner users (though I would argue that placing and sizing those gosh-darned circles isn't any easier, being that most counties are more-or-less squareish).
3. This approach would constitute a competing standard. Portability of location data between point-based and polygonal location-based scanners might be a problem.

Just some idle thoughts from a scanner newb....

Am I plumb loco?

 

[K9GTJ]

I assume most people use location based scanning the way Uniden intended and the way I use it. That is I was to hear my local county as soon as it is within receiving range and not waste scanning time when it is not. That is easily accomplished with the way Uniden implements location based scanning now.

You are suggesting I am only interested in scanning my county when I am within the borders of my county. I don’t personally like the idea.

However, what you are suggesting would not be hard to do with some slight changes from Uniden. Clearly the boundaries of counties and states are set in stone and available from many sources. Uniden could add them on a memory chip inside of the scanner.

End users could select a county using SAME codes since they are already defined everywhere (in the US). It might be handy to have the ability to expand the county range out 1 to 25 (?) miles so users could listen when not inside the county but where radio coverage exists.

Users could also define areas for using the old radius method for larger areas that exceed counties or more complex polygons as you suggest.

But all of this seems too complex so to answer your last question…

Am I plumb loco?

YES!

 

[kg4icg]

When you talk about squares, basically you are refferring to a grid system which in fact would be harder to define then a lat/long coordinate.For example. Maidenhead grid square format for which I live in is FM18IA. It covers quite a bit of square footage and isn't exact. Then there are other grid formats which use quite a few digits to mark it's location. Just stick to the lat/long coordinate system with radius. Unless you want to rack your brain and pull out your hair.


R Collins

 

[DaveNF2G]

I can see a use for polygons in the professional arena, where one might want to map actual transmitter coverage, which will practically never be circular in shape.

 

[Dave_D]

I assume most people use location based scanning the way Uniden intended and the way I use it. That is I was to hear my local county as soon as it is within receiving range and not waste scanning time when it is not. That is easily accomplished with the way Uniden implements location based scanning now.

Easy? I'm finding that this depends on geography. Here's an example: Try to isolate Carson City interference -- I live near Crystal Bay -- to it's county boundaries using Uniden's radius choices of 5, 10 and 20 miles.... Anything less than a 20 mile radius fails to cover the Carson City region (for when I travel to Carson and want Carson systems enabled). But at 10 and 20 miles, I get Carson traffic at home when I really don't want it. Either way, it's too much or too little. As another example, other counties in Nevada are too large for the maximum 50-mile radius Uniden allows for.

That said, I like your recommendations (not quoted). The SAME codes are a brilliant idea. And rather than specify locations for every system, as is done now, systems could be grouped into "locations." If not pre-programmed into the scanner, at least you need only define each location once, and then merely drop your systems in. Nice, eh?

 

[UPMan]

I make multiple sites (and in this case, systems) to isolate the coverage area to a better approximation of the system's use.

The large red circle around Arlington is the city set up as a single full-coverage site (lots of overlap into surrounding municipalities). This is the system as set up in the preload.

What I actually use is the set of smaller colored circles. Each set of smaller circles is its own multi-site system...set up so that when I'm in a particular PD district (N, E, W), I only hear calls for that district.

Would require more channel duplication with a conventional system, but there is generally plenty of room...

 

[Dave_D]

Yes, your image demonstrates nicely the best solution with the current state of the art. But I would still call it a workaround, or kludge solution, per my list of benefits, #8, "Resolves problem of duplicating entire system programs to describe location by two or more points."

I've been mapping the entirety of Nevada for some time now, since the BCT15 was first launched, and can only say that the circles are driving me nuts. Beyond the convenience factor, the RRDB (and everyone) already organizes sites by county. With SAME data and a little scripting, we could have instant location data for virtually every site overnight, for export via CSV. Voila! But then, this point/radii system is an entirely different language and so we're collecting location data from scratch....

Just my 2p.

ps. Upman, I bumped into a colleague of yours (?), Phil Henry, at the Silver State Classic road race in Ely, NV. Struck up a conversation with him about antennas and scanning having no idea his background with Uniden. Doh! Small world.

 

[slicerwizard]

Does anyone agree that location-based scanning would be improved if scanners permitted polygonal definition of scanning areas?

I agree completely. If one were to design a PC-based program to use real time GPS data to control which systems a scanner monitored, coverage areas would not be defined by simple circles; a developer would take the time to add more useful functionality. Off the top of my head, I would support multiple areas per system/site. Area types could include circles, rectangles, complex polygons, etc. If your current location falls inside any defined area, you monitor its associated system/site.

Thinking a bit more, I would add exclusion areas (don't monitor a given system while inside this area); that would handle a large valley, etc. These features would be implemented because they're useful and needed. If some users don't want the extra options, no problem - they'll just stick to one circle.

OK, enough daydreaming. As far as building any of this useful functionality in to scanners goes, your posting shows that there is a demand, but I wouldn't expect much action on this. Look at how long we've been stuck with ridiculous Motorola TypeII talkgroup ID's, e.g. 35312 instead of the real ID of 2207; we don't even get an option to change the input/display modes. The fact that the radius choices are apparently limited to 5, 10 and 20 miles tells me we're SOL - Uniden just isn't serious about this.

Now some naysayer will claim that the scanner doesn't have the horsepower to do more intelligent processing; never mind the fact that the 996 already has to evaluate multiple circular areas today (one per programmed system). Even the simple addition of allowing more circle definitions (with more radius choices) per system/site would give users most of the flexibility they want. We get flexibility in the number of frequencies and talkgroups a system can have, but not with important items like this. Go figure.

As presently implemented, this feature gives marketing what they want (GPS-based scanning!), but when you look under the hood it's a lemon.

Am I plumb loco?

You are if you expect the situation to improve any time soon.