Does anyone understand the order in which "near" cities are sorted? For example, if you type in Boston, it seems to start out alphabetically, but then Boston MA and other Bostons are not in order. Doesn't sort by distance either. I'm confused.
There are several discussions on this and it appears that there is really no logic to the way that they are ordered.
Random is the only explanation I have been able to discern.
When I do a WHERE TO? >> NEAR >> Different City and spell BOSTON and the DONE, they are sorted using the ASCII CODE Alphabeticaly. ASCII order:
See Chart at:
This is the way computers always sort!!
On my 340 they seem to come up in a random sequence. I think it just does a sequential read thru the data and displays them as it finds them.
As I scroll down the list Boston, MA precedes Boston, GA and follows Boston, VA. Sorry for my code ineptitude but does that follow the ASCII principle? Thanks.
Lost on this issue, but not on the highway.
I think it sorts the results by place size (from smallest to largest), then alphabetically by state. In other words, it will first list all the tiny place names called "Boston", even if the place has negligible population, followed by towns, then cities.
A better way would be for the GPS-R to return the results in proximity order from nearest to farthest.
This can cause a problem with common place names like "Springfield" if your unit has a max limit for results. For example, let's say I want to use Springfield, Massachusetts as a destination. If I simply type in "Springfield" without designating the state, it will list all the tiny "Springfield"s throughout the US and Canada, then the mid-size towns, and finally the cities.
Quit guessing. Believe me, it sorts using the ASCII Code chart.
The main ASCII Codes used in the "City" searches are these ones for "Space, Apostrophe, Comma, Dash, Numbers, Upper Case Alphabet, and Lower Case Alphabet.
These are in an order within the ASCII chart numerically:
48-57 Numbers 0 to 0
65-90 Upper Case Alphabet
97-122 Lower Case Alphabet
see the ASCII chart for all the codes listed numerically:
So here is how it works:
1. The city Names including spaces between words, commas, state abbreviations and any other characters that make up the total word or group of words are divided into columns, each character is in a column by itself. Thus the city name "Conasauga Heights, TN" would have 21 columns.
2. The sort then begins in column 1 sorting according to the ASCII Code in order 1 to 127. Then sort’s column 2 and so forth until it has sorted all columns.
If you type " CON " into the spell and the DONE, you will receive the following:
Cona Brava, MA
Conanicut Park, RI
(There are a lot more but we will use only the 1st 4 for this study.)
As you notice the first 3 columns of letters are CON just what you asked for. The 4th column is an "a"(number 97) which means there were no other characters lower (numbers 1 to 96) in any city name stored in the GPS, and there were no characters past the "a"(numbers 98 to 127. So it places all 4 names on the list to continue sorting through.
Now when sorting the 5th column in the 4 names above. It found a name, which had a space (Number 32) so it places "Cona " at the top of the list. It is now through with the sort on the city name Cona Brava, MA because there was no more city names that had a " "(Space number 32) in the 5th column. So it doesn't need to use that name any more, thus placing it at the top of the list.
It now sorts 5th column of the 3 words left and compares the characters to the ASCII Code chart and the first code number it finds is a "n"(number 110) which is the next lowest code number so places all city names (3) having a "n" as their 5th character next under "Cona Brava, MA. It would then sort the 6th column in all the city words that had "n" as their 5th column character and find the lowest character number "i" in 1 word. Being no other word has an "i" in the 6th column it places that name (Conanicut Park, RI) at the top of all names with "n" as the 6th character. It continues to sort the 6th column for the next character and finds a "t". Both words left have a "t" as their 6th character so goes on to the 7th column and finds a ","(comma number 44). They both have a comma so it checks the 8th column and finds a " "(space number 32) in both words. Then it checks the 9th column and finds the lowest match is a "A"(number 65), only 1 name has a "A" in column 9 so that word (Conant, AR) is complete and placed under Conanicut Park, RI.
Thus the last of the 4 words has a "C"(number 67) in the 9th column and would be the last word sorted and places last in the sort.
Quit guessing. Believe me, it sorts using the ASCII Code chart.
In http://www.poi-factory.com/node/11817 , Asianfire reports the following sort order:
Williams,TX @ 1275 Miles
Williams,VA @ 71.5
Williams,AZ @ 1923
Williams,CA @ 2396
Can you explain?
Thanks for a great explanation of ASCII!
Yes I can explain it somewhat. When you put spell Williams only and hit DONE you will see a list starting with "Williams, AL" through "Williams, VA" there are 5 Williams, XX following the Williams, VA those being AZ, CA,IA,MN,and SC.
These 5 are sorted this way because of a extra hidden character as the last character in the word "WilliamsX, X being the extra character. The X should be an END OF TEXT character(number 3)
If spell the word "Williams" with nothing else you get the above sort followed by Williams towns with 2 names starting with Williams Bay, WI. If you spell "William " the blank being a space you get William towns with 2 names starting with Williams Bay, WI. If you spell "Williams," you get nothing, which means the the comma is not in the data base and only inserted into the list afterwards comma delimited text then sorted and sent to the screen.
There has to be a problem with the data base with the Williams names with a hidden character after the s in Williams, as I stated before.
I know that sorts can be very tricky. I ran into this problem years ago back when I was programing in basic on a Trash80 (Radio Shack TRS 80)in 1978. As I found out any little error in the data list you were using would scramble the sort just as it is doing in this case.
In the above problem a character of END OF TXT(number 3)should be following the word "Williams". In looking at the chart the extra character would have to be a character between Number 3 and Number 32. 3 being the END OF TEXT and 32 being SPACE. We know this because looking at the sort using "WILLIAMS" you get WILLIAMS, XX followed by the 5 Williams, ZZ (ZZ being the Williams not in sort order)then followed by Williams Bay, WI etc. the Characters 4 through 31 are non-printable characters and any one of these will cause the problem we all are experiencing. If it was any other character 32 to 126 they are printable and would show on the list. The last character 127 (DEL) could also cause the problem because it is also a non-printable character.
I know this may be a little confusing but it is what it is.
Searches using "Cities" or "Near, A Different City" show results that seem to be in alphabetical groups of states/provinces.
Here are some examples:
...and the "alphabetical" is sometimes mysterious, as in IN (Indiana) followed by IA (Iowa) or ME (Maine) followed by MA (Massachusetts).
Could "alphabetical" grouping be by state name vs abbreviation?
And why are there multiple groups??
Your explanation, while completely possible, would require multiple different accidental characters (up to 8 in his Springfield example) to explain the sort. The fact that the Canadian provinces are grouped together leads me to believe that there is another (non-printing) field or two that are being included in the sort.
Yes I agree, there are probably a few extra non-printable characters in the examples you showed from WAAASup.
I only used the limited sort (of four lines) shown by Budbtl (BOSTON) to show how sorting is done using ASCII Codes, and what probably what is causing the errors.
There are probably a lot of errors in the DB being used. The probable cause of the errors in the data base may be that many people were working on compiling it.
This is only a theory as to why the data base has so many errors. But in looking at the SORT from the DB it does show errors there.
Garmin's tech support thought that cities were sorted alphabetically until the Boston issue was directly pointed out. Only response was that he would report this to the programmers for review.
Yes it is sorted Alphabetically, but done in the sort order prescribed by the order set in the ASCII Chart 1 to 127.
If you look at the ASCII chart, you will see the order the sort takes.
1. Special Characters first:
2. Then Numbers
3. Some more Special Characters
4. Next Upper Case Alphabet
5. Some more Special Characters
6. Lastly Lower case Alphabet
If you have EXCEl on your computer you can experiment with the order of sorts. Type in the same word, but use different special characters in front of it. Then after you type in a few ( about 11) then sort the column and the compare it to the ASCII chart.
An example would be as follows:
after you type them and sort them, compare it to the original order as written.
It would appear that cities are first selected by installed mapset(s)- e.g. City Navigator or basemap.
Cities are then sorted alphabetically by country and province/state name.
Let me use Santiago as an example:
Santiago(1) is the list of cities from the City Navigator North America NT 2008 map.
Santiago(2) is the list of cities from the nuvi 650 basemap.
Wait! you say...the "alphabetical" seems somewhat mysterious, as in BOL,BA,MA,RS,CH or PAN,PRY,PER,MN,PA.
Let's see --- for countries we have Bolivia, Brazil, Chile, Columbia, Costa Rica, Dominican Republic, Mexico, Panama, Paraguay, Peru, USA
...and for provinces/states, we have some Brazillian ones (BA,MA,RS), some Mexican ones (BCS,CHIS,COL) and some U.S. ones (MN,PA)
Theory seems to work for me
You can verify the basemap theory by turning off maps (Wrench(Tools),Maps,Map Info,uncheck all maps) and looking at Bentbiker's quoted cities from Asianfire and me - e.g. Williams or Homer (or Simpson (d'Oh!)).
There are map and hardware dependencies. Compared to our nuvi 650 with 2008 maps, our 680 with 2009 maps lists Puerto Rico ahead of Arizona and is missing BCS,COL,MN,PA from the basemap.
I wish garmin would update its software to sort the cities by the nearest to farthest or at least let the user be able to enter in the state when searching for a "different city" under the "near" tab, that way I don't have to look at 20+ results
terms | privacy | contactCopyright © 2006-2019