Database "radius" maps not accurate for large plots

[Jay911]

I just noticed something that is of mild concern to me.

A recent DB submission intended to cover all of the province of Alberta had a position of N54.5° W115° and a radius of 440 miles. (For all intents and purposes, that lat/long is the geographic center of Alberta, discounting the portion in the SW along the Rocky Mountains which is in British Columbia.) Were I able to submit using the Rectangles boundaries, I would make the top left corner of the province/boundary N60° W120° and the lower right N49° W110°.

According to an application which draws radii on Google Maps, this is what "54.5,-115 440 miles" results in:

However, this is what RR draws:

The RR circle is drawn at a radius of about 707 miles (gauged by zooming and panning; it bisects Portland, OR, and moving the radius on the FreeMapTools site to that point shows me 706.499 miles).

I'm not particularly concerned about how it will impact radios; I've confirmed that my radius drawn on FreeMapTools and independently using the Measure Distance tool on Google Maps is correct, but it might confuse people who venture into the site/category details page expecting to see how wide of an area their favorite system will cover.

I tried it on a relatively small radius (10 miles) elsewhere in the DB and the radii seemed to match up. I looked for another large area and found one in TxWARN P25:

Coordinates for the system as shown by RRDB:

Measurement of those same coordinates and radius on Google:

Notice that the FreeMapTools radius does not enter Oklahoma nor Mexico, while RR's depiction does.

I suspect that the larger the area (radius) is over a certain value (which I didn't find), the calculations will be out by an increasing factor.

Again, I don't think the actual area is wrong in the DB as far as the radio data goes - unless someone submitting it used the RR depiction of the radius to determine if the coverage area was correct.

 

[902]

It might be a nice estimation tool, but in plotting system coverage and interference, we use the FCC's R-6602 formula with a land mobile radio derating factor. It takes terrain into consideration to a certain extent, and then drawn a signal contour based on the point derived in the formula for the value required. Sometimes there's need for something more accurate (like when looking for a frequency north of Line A and getting an HIA rejection from Industry Canada), and the model used is something else, like Longley-Rice with a certain confidence weighting.

These are a nice rough guide, but shouldn't be taken as concrete coverage predictions. I rarely see perfect circles in modeling these with professional tools. It's always varied by terrain, clutter, and antenna characteristics.

The other thing to consider is map projection. In several early variants of the mapping I use at work, a circle radius actually was drawn "ovoid" (egg-shaped). Depending on the projections chosen, large areas might distort.

 

[Jay911]

I'm not talking about estimating actual coverage for a system, I'm more concerned for the scanners that make use of the radius/range functionality. If a submitter or an admin makes a "range circle" based on the footprint that the RR site shows, they may be unintentionally drawing a much smaller range than they want. For example if I tried to cover all of Alberta with a range circle and used the RR site's circle as an example, my range would be much smaller than if I'd measured with another site and used that value.

Put another way: When asked to draw a circle with radius X, when X is larger than a certain amount (which I've not yet determined other than 10 < X < 230), RR draws a circle with a radius much larger than X.

 

[902]

Ah, my bad. I didn't know that's what the function was used for. I don't know, but will standby for the answer.

 

[blantonl]

Interesting find... something is off in the public facing display for location data - the admin tools all properly reflect the coverage circle. I'll have a look at it...

 

[blantonl]

This was a good catch - I've rolled a fix out.

We were incorrectly converting miles to km in some cases.

Should be all good to go now.

THanks,

 

[Jay911]

Thank you!