Originally Posted by GeekGirl
I think something broke on the user entry side. I get no error messages for the following invalid inputs. Analysis proceeds.
, no street name
+ zip code (should be error of no street name for lookup): WARNING: Address was only resolved to street level accuracy. The accuracy of this report may be limited.
No zip code, just "123" for street number (should be error of no zip code and no street name). No zip code / street seems to default to somewhere near Providence RI / Bedford MA (WJAR is closest).: WARNING: Address was only resolved to street level accuracy. The accuracy of this report may be limited.BUG:
The above may be related to a bug I just found. Enter "123" and no street name, zip=19067, ant=30 and I get stations around northern PA (26 mi. from WBRE-DT). Enter no street info, zip=19067, ant=30 and I get the correct stations (9 mi. from WNJT).
Thanks for all the constructive comments!
The reason for your strange result is that Pennsylvania actually has a highway number 19067 (maybe a service road of some kind?). The engine is trying to provide a location for the street address 123 on highway 19067.
Part of the problem lies in the tough task given to the geocoder. These engines need to convert an arbitrary string, like "100 1, PA", into coordinates. There are all kinds of ambiguities that can arise like is that "1st Street?" or "1st Avenue?" or "Highway 1?", is that "North 1st?" or "South 1st?" Most geocoders are designed to be very forgiving because in many cases, people are trying to look up and address in an area they are not familiar with. Most geocoders will try to provide an answer even if the address is under-determined. Most will even try to "fix" erroneous entries because maybe the user didn't spell the street name correctly or did not type in the correct zip code. What makes this even more challenging is that the geocoders also allow multiple styles of queries like "1st & Main, PA" (find intersection), "Convention Center, CA" (find place by name), "Mainville" (city only), and "BWI" (airport codes and other abbreviations).
In this particular case, I think the geocoder is trying a bit too hard to provide an answer no-matter-what. Even though my intent is to have 19067 be a zip code, the engine is looking for all the possible ways to interpret that value. When I enter "1" as the street address and zipcode 19067, I get the location of US Hwy 1 in Morrisville, PA (a fair answer in my book). When "123" is used as the address, it returns a result on highway 19067 out in the middle of nowhere, presumably because it can't find a road called "123" in zip code 19067 (that's re-interpreting things too far in my book).
The accuracy code returned by the engine lets me know that it was only able to resolve a street name, but I can't tell if it has mis-interpreted the wrong street name or if the user really entered just a street name, which might be a perfectly legitimate thing to do if you're running a check for a friend's house but don't have their house number.
The Yahoo geocoder seems to be less wild with its search results for this particular case, but it still seems to suffer from similar problems, just in different places. Both services are aggressively trying to satisfy an under-determined, ambiguously defined query. Even though most people would think that an error should be returned, there are a lot of cases where the geocoder will think it has an answer for you.
I'll have to search around and think about ways to help detect or prevent this problem. Off hand, I can't think of any sure-fire solution to this short of requiring the user to confirm their location on a map. That's doable, but it will require quite a bit more development. If there's an algorithmic detection/fix for this, I could get it done a lot faster.
In the interim, it's up to the user to do their best to enter an unambiguous address specification.
What does "The accuracy of this report may be limited" mean? I get that for all inputs.
If the user's location is not determined to an exact address or specified coordinates, then this warning will be displayed. It usually means that the user entered partial information (e.g., only a zip code), or the geocoder was not able to correctly resolve the exact building address.
To make the warning go away, you need to enter a fully qualified address or provide exact coordinates. The reason for the message is that in many hilly neighborhoods, small location offsets can cause very different results to be generated. I think I will change the message to read "To get more accurate results, enter an exact address or coordinates."
Looks like you have "over-achieved" on colors-
I think the grouping of Azimuth colors on the plot table should be removed. Too confusing and detracts from the rest of the table color info. You have more than enough colors elsewhere. The radar plot is ideal for this as-is.
I would remove the outer "border" ring from the radar plot. Nice as a background, but is distracting from the rest of the plot.
Yes, the added colors make the page look more "busy". I have my own apprehensions about having too much clutter in the output. I've actually tried several variations on this feature to try and minimize the visual impact while adding information.
The problem that I'm trying to solve is that I'd like to differentiate certain individual transmitters from the big clusters of antenna farms that exist in many places. I wanted to make the handful of "rogue" transmitters stand out from the rest of the list so that it's obvious that certain channels will require a separate antenna or rotator to get.
If you get lots of transmitters from a bunch of different directions, then this coloring scheme doesn't really help. However, if you've got lots of transmitters coming from just one or two main clusters (which happens quite a bit), then this makes it a lot easier to spot the transmitters that require special attention.
I understand your reaction since I prefer the clean look as well, but I think I'll let it sink in for a while and maybe play with some other options before I decide to ditch the feature. Your comment is definitely noted. I just need some more time to mull it over.
The spectrum plot and table drop all background colors when you go to "All" channels. Is this a bug?
Nope. This was intentional because I can't show a colored background that simultaneously represents the analog and digital reception thresholds. I think that adding a mixed-mode threshold coloring would create more confusion than anything else. People who are paying attention might notice that the analog and digital levels are different and be inspired to learn why analog and digital TV have different thresholds.
Actually, when I get around to it, I plan on writing something to explain that on the web site. I just need to juggle my time between continued software development, coverage map processing, and writing more informative documentation, not to mention my regular day job.
Keep going, good stuff.
Thanks for all the feedback and suggestions! I want the site to informative, accurate, and easy to use/understand without any marketing hype or obfuscation. I need all the help I can get to bridge the space between being highly technical/detailed/accurate and being easily understood by everyone.
I appreciate all the useful comments.