Excel

you might have lost the selection of the Column, so it applied it to the entire spreadsheet.

Make sure you did replce all the commas.

As you state the latitude and longitude changed, what program did you use to generate them? It could be you mistakenly used a comma instead of a period if you entered them manually.

As to removing commas, the only column that may need modification is the third column, and that's only if there is a fourth column.

I wrote this program in the same Excel that I made the changes. I only used column's A, B, and C.

What is strange is that the Longitude only changed by a few degrees and some disappeared. And only a few of the Latitude's changed. I have 535 lines and over 1600 comma's. At least it did change the comma's to the semi colons. I don't understand.

Sounds like the number formatting on the cells in those two columns is the culprit, it should have a general formatting since other formats may round up numbers.

Main reason I only used Excel once and then moved on to Notepad I like to see what is going in the file.

Now I use Extra POI Editor

Humm! I have never thought of that. Will have to try it. Thank you,

What am I missing here? I always write csv files using commas. In the forth field where I use commas between things like city and state I just enclose that whole field with quotes, then when done I load the file into Excel to make sure I didn't miss a quote somewhere.

The general consensus is that 2.6.0 does not like commas in the 3rd field.
If the file is 4 fields then the 3rd field would be the name. Commas in the 4th field seem to be ok if enclosed in quotes.
If it is a 3 field file then any commas in the 3rd field will mess it up.

I have 2.60 and have loaded csv files with commas in the fourth or column d with no problem.The comma problems is column 3 or c column.As long as you put the name in column c you will have no problems and leave out the commas.Some users for some various reasons only using 3 columns.Making then column 3 a problem with the commas. Not sure about most members I prefer to have a name in column 3.That allows me the option you use the all tab for the custom pois and not having to guess what some are.

My gps and some others only use column A, B, and C and ignore all of the other column's.

POI Loader 2.6.0 does not like special characters in column c only if there is a column d. IOW, building a 3 column POI like you need for ALK or Tom-Tom OV2, it will accept commas or special characters in column c. JD4x4 stated it best - commas are acceptable in only the last column of a CSV format file.

I know some models use only 3 columns like the Tom Tom.When you go to the download site for the US Firearms it lists Garmin Csv and Tom Tom ov2 for download.I guess that leads to some confusion.One using 3 columns and the other 4.Jon said he was going to look into that and try to do something.Creates problems both side.A Garmin user does a file with 4 columns and it has to be modified for Tom Tom.Same with 3 columns to be modified for Garmin.

Does the Garmin have to have the 4th column? As long as you do not have comma's in column 3 there should not be a problem as long as Garmin will accept it. Just asking.

Yes it will accept it with no commas.The problem comes up when you select the all tab for a category and several show up.The ones without a name in column c.You have no idea what it is when mixed with others with name in column c.Plus when you get the arrival notice for that poi it is based on what is in column c.To long and it gets cut off.Most files like that I just add the name to avoid the problems.Maybe jon will have a solution.If it shows as a Garmin csv for download you kinda expect it to be 4 columns.

For the time being. When I upload a csv file I will state that it is for .ov2 formate only. Maybe this will help.

I guess what would really help is if I learned how to write a file in .ov2 instead of csv.

Like you said, we will just have to wait and see what Jon comes up with.

Garmin states the fourth column is an optional column. The three required are the first 3. The 4th provides additional information or a description of the information in the 3rd column.

As to writing for an OV2 format, it is no different than writing a 4 column file. I don't think the site will accept a file with an OV2 extension it's either a CSV or GPX (which are really only ASCII text files). Both can be edited by any plain text editing program.

It may be optional but getting the arrival message using a 3 columns csv file with that much text in it sure not the best arrival notice to receive.

I will for the time being write two files. One called, example, ABC_csv.csv and ABC_ov2.csv. Hopefully this will help Miss POI. Column 3 will just have the name and column 4 will have the address for the Garmin users.

Open for Comments.

A CSV file is not a native Excel file, it is just a text file that Excel happens to be able to input and output. Any text editor should edit it fine. Fields are separated by commas (which is what the C in CSV stands for (Comma Separated Vectors (or variables)). But there is a simple rule for including commas in the field, which is perfectly valid and will load properly. Just quote the field, and a comma inside quotes will be part of the field, not a field separator. Thus "Pittsburgh, Pa," or "John Smith, Esquire" are each one field but N.Y., N.Y. would be interpreted as two fields, each with the value N.Y. (which is likely not what you wanted).

I suspect that Garmin will fix the issues with commas in POILoader v2.6.0 .. it looks like a bug to me, rather than intentional.

Of the 'anomolies' that I found in v260, one is an input error if (a)there are 4 columns, (b)column 3 data is in quotes, AND (c)there is a space between the last column 3 quote and the col 3-4 field separator comma.

Fortunately, Excel DOES NOT put an extra space after the last quote and the field separator comma when it writes a csv file.

Unfortunately, v260 also has a bug that if there are (a)4 columns and (b)column 3 is quoted & (c)contains a comma, even if col 3-4 is separated correctly ... the column 4 data is ignored with no error given.

What this means.. until v260 is fixed, no commas in col 3 (use some other character?) if you want 4 columns. Or use v2.5.x

And be careful not to use spaces around field separator commas if you are hand-editing with Notepad, etc.

Otherwise, Excel works just fine. Probably better than hand-editing since there's no chance of putting a space after the last quote & before the field separator.

Examples:

• -77.000,38.000,"My POI, Inc."

Works fine

• -77.000,38.000,"My POI; Inc.","My comment, etc"

(Note use of semicolon)
Works fine

• -77.000,38.000,My POI; Inc.,"My comment, etc"

(Note use of semicolon and no quotes in col 3)
Works fine

• -77.000,38.000,"My POI, Inc.","My comment, etc"

No Error, but no comment (col 4) written

• -77.000,38.000,"My POI; Inc." ,"My comment, etc"

(Note the space here ........... ^ .. but use of semicolon)
Input error, line not written & input stops

• -77.000,38.000,"My POI, Inc." ,"My comment, etc"

(Note the space here ........... ^ .. and use of comma)
Input error, line not written & input stops

Clear as mud? Have fun.

Wrong. Have you not read the prior posts in this thread??

Garmin has arbitrarily decided not to follow standard protocol. Which is why we now have to spend so much time "fixing" their mistake.

actually you are incorrect. the Quote turns off the parsing of values until it hits another Quote then it is turned back on, everything inside the Quotes is considered a single Value/Field for input to the program.

Reference "Fields that contain a special character (comma, newline, or double quote), must be enclosed in double quotes" from the wiki definition for CSV.

Essentially everything inside the Value/Field goes as input to the program, it then becomes up to the program to determine format of the field that the program will accept. It would be in Garmin's purview to change it anyway it see fit, the bad thing is they never gave anyone a heads up on what they did, or for that matter published the format they expected the fields to be in.

If you go back to the Wiki article you will note the word may - as in may interpret - rather than shall. This makes the interpretation of special characters permissive rather than required.

You are correct about the requirement that fields containing special characters are to be enclosed in double quotes. But the programmer has the option, because of the permissive "may" as to if they will honor the special characters or not. That's the entire rub. The programmer has chosen to allow special characters in the last field, but not the third field if followed by a fourth. So, even though there is a recognized "standard" the permissive language regarding allowing special characters means the programmer can either parse for the separator or not when he sees the double quotes.