Coordinates in the database

[dlwtrunked]

All he coordinates in the database should be fixed. Things like "W -77.12345" should actually be "W 77.12345", but can also be written as "E -77.12345" (though software often will not like that). This is standard geo-positioning. If one puts "W" then the "-" not only is not needed, it is just plain wrong. Putting a "W" in effect cancels the "-" and "W -77.12345" is the same as "E 77.12345".
(I am a mathematician who has worked with geo-positioning. ) In the geo-positioning world, this error is considered the sign (pun intended) or someone not knowing what they should know.

Dropping the erroneous negative sign will also then allow google maps to work, For example N 38 00 00 W 100 00 00 will be north of Dodge City, KS. Google will not even find N 38 00 00 W -100 00 00 as it dislikes the -.

 

[GTR8000]

The coordinates are correct, it's just the formatting on certain screens that include a N or W prefix, but those are not actually part of the coordinates that are stored in the RRDB. When we enter coordinates, we enter them as simply: 38.1834661, -77.6497113

Take this system as an example:

Spotsylvania County Trunking System, Various, Virginia

Spotsylvania County Trunking System Profile

www.radioreference.com

If you click on the site name, you wind up on the Site Details page, which inserts the N and W prefixes:

Spotsylvania County Site: Simulcast

Spotsylvania County Site: Simulcast Details

www.radioreference.com

However if you view the Downloads and Reports page, then the Site Location Data Report, you can clearly see that the coordinates are correct:

RR Database Home

The most complete database of radio communications data

www.radioreference.com

Stating the obvious, if the coordinates were "wrong" all across the RRDB, then the Uniden location based scanning wouldn't function correctly.

 

[dlwtrunked]

OK, I understand, by screen you mean web pages, then those pages need to be fixed.

 

[Reconrider]

OK, I understand, by screen you mean web pages, then those pages need to be fixed.

As already stated, they’re correct. If it’s an issue for you, take the 1.2 seconds and fix it on your app that you’re using. It works correctly for proscan and sentinel when importing to my sds100 and sds200.

 

[dlwtrunked]

As already stated, they’re correct. If it’s an issue for you, take the 1.2 seconds and fix it on your app that you’re using. It works correctly for proscan and sentinel when importing to my sds100 and sds200.

It is not an app problem, we are talking about incorrect RR webpages as they have pointed out the problem is in the webpages not the database itself to program scanners. It is not only wrong, it forces one to have to edit every time one copies and pastes (like to a Google maps). The error is that certain (many) RR web pages are incorrectly displaying things like "W -78 ..." when that should be "W 78...". Once one displays longitude with a W", one must remove the "-". As an example, look at
Fort Belvoir Site Details (Joint National Capital Region)
In the table, Longitude should be "W 77.154582" not "W -77.154582". ("W -77.154582" is actually the same as "E 77.153582" which is not the right place.)
(Note that I am a mathematician who has done geo-positioning work as an employee for the U.S. government and well-versed in such.)

 

[wa8pyr]

This is being looked into.

 

[GTR8000]

The error is that certain (many) RR web pages are incorrectly displaying things like "W -78 ..." when that should be "W 78...". Once one displays longitude with a W", one must remove the "-".

Actually, it should just be -78. Once the E and W are dropped, the presentation of the coordinates will conform to DD (Decimal Degrees) standards. I'm sure you already know that, being an expert in the field.

 

[mmckenna]

"The nice thing about standards is that there are so many to choose from."

-some guy I used to work with.​

 

[dlwtrunked]

"The nice thing about standards is that there are so many to choose from."

-some guy I used to work with.​

This is not really an issue about standards. W 77 is not the same as W -77. If I say go west -77 degrees, you actually go east.

 

[dlwtrunked]

Actually, it should just be -78. Once the E and W are dropped, the presentation of the coordinates will conform to DD (Decimal Degrees) standards. I'm sure you already know that, being an expert in the field.

If you drop the W, E (east) is understood as default so W 78 is -78 (or also 360-78=282, some internation agencies use this form as they always use E and not want to use a - sign). So it can be listed as W 78 or (E) -78 or (E) 282 but not W -78. The (E) above means the E is optional.

 

[GTR8000]

If you drop the W, E (east) is understood as default so W 78 is -78 (or also 360-78=282, some internation agencies use this form as they always use E and not want to use a - sign). So it can be listed as W 78 or (E) -78 or (E) 282 but not W -78. The (E) above means the E is optional.

You're making it more complicated than it needs to be.

0 degrees latitude is the equator, and 0 degrees longitude is the prime meridian. Any DD formatted coordinates that don't include the negative sign are understood to be north of the equator/east of the prime meridian, and of course any that do include the negative sign are south of the equator/west of the prime meridian.

41.0, -78.0 is perfectly fine, and is how the coordinates are already stored in the RRDB. Plug that exact string into any mapping software and it has no problem whatsoever making sense of it.

 

[wa8pyr]

You're making it more complicated than it needs to be.

0 degrees latitude is the equator, and 0 degrees longitude is the prime meridian. Any DD formatted coordinates that don't include the negative sign are understood to be north of the equator/east of the prime meridian, and of course any that do include the negative sign are south of the equator/west of the prime meridian.

41.0, -78.0 is perfectly fine, and is how the coordinates are already stored in the RRDB. Plug that exact string into any mapping software and it has no problem whatsoever making sense of it.

He's not debating that; he's merely pointing out, and you acknowledged, that the way it's displayed on the web page in some locations (with the W and E or N and S prefixed) is incorrect. And I noted several posts ago (Post #5, to be precise) that the issue is being looked into. There's no reason to continue thrashing this out.