Generic POI Data
Tue, 01/15/2008 - 8:34pm
 16 years
|
Is there a generic csv format for POIs for multiple GPS brands? If not what is the best approach to make the POIs available to user of different brands? Or is another file type like gpx better for general POI distribution?
An interesting discussion point.
Is there a generic csv format for POIs for multiple GPS brands?... Or is another file type like gpx better for general POI distribution?
Theoretically, GPX is the answer. Or at least, that's its goal.
However, as to who (amongst GPSr manufacturers) supports it, I don't know (other than Garmin, of course). Even then, they had to add a lot of private extensions, which have not been adopted into the standard.
With csv files, you would, at the very least, have to add some headers, to describe what each field means. That would bring both formats to same level of functionality - but wouldn't actually solve any of the real-world issues - now nothing would understand them.
The other approach, is that taken by the gpsbabel project - ie a conversion program with a variety of input/output modules for different formats.
In an ideal world, you'd probably upload to POI-Factory using an agreed standard format, and when downloading, the data would be formatted 'on-the-fly' for your Target Device.
What is GPX?
GPX (the GPS eXchange Format) is a data format for exchanging GPS data between programs, and for sharing GPS data with other users. Unlike other data files, which can only be understood by the programs that created them, GPX files actually contain a description of what's inside them, allowing anyone to create a program that can read the data within.
------------------------ Phil Hornby, Stockport, England ---------------------- http://GeePeeEx.com - Garmin POI Creation made easy »
Generic POI = CSV
Is there a generic csv format for POIs for multiple GPS brands?... Or is another file type like gpx better for general POI distribution?
With csv files, you would, at the very least, have to add some headers, to describe what each field means.
Hate to disagree but.........
It appears to me that CSV is universally supported by most brands AND it is plain text so it can be created/changed with any plain text editor.
The format is so simple:
Longitude,Latitude,Name,Description
that there really is no need to have any headers.
Anybody who can't figure out what those 4 fields ARE by looking at the data probably shouldn't be messing with custom POIs in the first place.
Magellan Maestro 4250// MIO C310X
.
The LG models don't follow this format.
.
Hate to disagree but
To be expected on this topic - because there's not an obvious right answer!
It appears to me that CSV is universally supported by most brands.
The format is so simple:
Longitude,Latitude,Name,Description
that there really is no need to have any headers.
Well that is a csv layout that Garmin's POI Loader understands - and I'm guessing that Magellan software does too? But it's not exactly a comprehensive list, is it? How about TomTom, Lowrance, Mio, Sony, Medion, Navigon, Navman...
In that particular csv layout, what does the 4th field represent? A short comment or a lengthy, formatted description. Or just anything you fancy? If it's formatted for presentation, how is it formatted - with embedded <CR><LF>s or with <html> or using some other means?
Perhaps you take the approach, that all POIs to be shared with others have to be reduced to their lowest-common denominator to achieve compatibility? ... and if people subsequently want the all-singing, all-dancing version, they have to obtain it directly from the author?
Re: gpx - while acknowledging that it is incomplete, there is at least an active 'working' group that might be willing to take our suggestions to create a gpx 1.2 specification. In time, its use would be adopted by all the current gpx users. (It would be nice to give something back to Google
) ... and who knows, maybe the other GPSr manufacturers would eventually follow Garmin's lead and adopt gpx?
Anybody who can't figure out what those 4 fields ARE by looking at the data probably shouldn't be messing with custom POIs in the first place.
Where's this location (53.000,-2.00)? What date do I mean by "11/1/2001"? - It's easy to generate confusion by not having an actual, agreed standard...
Most of the things I mess with, I don't understand
------------------------ Phil Hornby, Stockport, England ---------------------- http://GeePeeEx.com - Garmin POI Creation made easy »
Standards
Is there a generic csv format for POIs for multiple GPS brands? If not what is the best approach to make the POIs available to user of different brands? Or is another file type like gpx better for general POI distribution?
After getting my first GPS a while back and learning how to create POI's, I have noticed that many of us do them differently. My suggestion is that a team of people come up with standards. If different models have different standards, then maybe the POI's should have standards within the models and when downloading a particular POI, you would choose from a list that has your POI in the standard for your GPS. Just a thought.
Larry - Nuvi 680, Nuvi 1690, Nuvi 2797LMT
Standard csv
What is standard? To say that Magellan and Garmin should have the same standard for csv files is like saying Chevy and Ford should have the same standard for engine displacement ... "ain't gonna happen!". Garmin has set their standard for csv as shown in the Help section of their POI Loader. That is:
Longitude,Latitude,Name,Description (Optional)
This isn't something we made up ... it's stated directly from Garmin. And since POI Verifier is designed around Garmin, that is the standard POI Verifier is written on.
RT
"Internet: As Yogi Berra would say, "Don't believe 90% of what you read, and verify the other half."
so...
What is standard? ... "ain't gonna happen!".
So - are you arguing in favour of the 'correct' flavour being built on-the-fly at download time? ... or that files should be kept on POI-Factory in whatever flavour they're uploaded? (and it's the downloader's problem as to how to re-format them)
------------------------ Phil Hornby, Stockport, England ---------------------- http://GeePeeEx.com - Garmin POI Creation made easy »
Please Quote what I said
What is standard? ... "ain't gonna happen!".
So - are you arguing in favour of the 'correct' flavour being built on-the-fly at download time? ... or that files should be kept on POI-Factory in whatever flavour they're uploaded? (and it's the downloader's problem as to how to re-format them)
You'd make a good politician ... you didn't quote what I said. I said like saying Chevy and Ford should have the same standard for engine displacement ... "ain't gonna happen!". That means Chevy and Ford ain't gonna do it, not what you quoted. Next time please quote what I said, not what you want me to say.
I'm saying that Garmin has their standard; and when working with Garmin, use their standard.
RT
"Internet: As Yogi Berra would say, "Don't believe 90% of what you read, and verify the other half."
.
I quoted what I thought was the gist of your argument - and was seeking clarification of what you meant.
------------------------ Phil Hornby, Stockport, England ---------------------- http://GeePeeEx.com - Garmin POI Creation made easy »
Generic POI Format
Perhaps you take the approach, that all POIs to be shared with others have to be reduced to their lowest-common denominator to achieve compatibility? ...
Yes. Exactly.
OR
At least they should be identified as to what Make and Model they were created for.
OR
They should be divided into different directories here by Make and Model.
I think that a user should not have to download and look at a file to find out how it is formatted.
Example: Garmin "multi-line" formats are confusing and difficult to deal with if you don't know what they are.
If everything is going to be a .csv, then it should be in a (lowest common) standard format OR it should be identified that it is something else.
Easy really and just common courtesy but it can be REALLY important to those who are new to the subject and/or are having a hard time understanding it.
Magellan Maestro 4250// MIO C310X
Manufacturers
Quoted in part
... Example: Garmin "multi-line" formats are confusing and difficult to deal with if you don't know what they are.
If everything is going to be a .csv, then it should be in a (lowest common) standard format OR it should be identified that it is something else.
If the manufacturers can't agree on a common format, be it csv or gpx, how are the users to agree? I sure don't believe I should have to reduce the capabilities of my Garmin POIs just because Magellan or Tom-Tom format aren't as inclusive; and, in return, I believe if I want to use Tom-Tom or Magellan POIs, I should be willing to convert and adjust them accordingly.
As with anything, 'confusing' is related to ones knowledge of that item. As you stated, Garmin "multi-line" formats aren't confusing if one is familar with them.
When we discovered the nuvi 350/360 had a problem displaying linebreaks, we didn't decided all GPS units should conform to our required <br> linebreaks. Instead, we worked on a solution and wrote a program to convert the linebreaks to our requirement. Maybe instead of forcing Garmin users to step down to Magellan and Tom-Tom POIs, Magellan and Tom-Tom should step up and manufacture units compatible with more informative POIs.
RT
"Internet: As Yogi Berra would say, "Don't believe 90% of what you read, and verify the other half."
Computers and data in general
This isn't a Garmin or Tom Tom issue, this is only a small sampling of the lack of standards in the world of computer technology. While there are some standards, everyone follows them their own way.
My first IT job was processing mailing lists for a direct mail company. We worked with dozens of file formats from dozens of sources, CSV files without a header, CSV files with headers, CSV file with CRLF (carriage return line feed) characters after each record, comma delimited, semi-colon delimited, etc. We spent countless hours converting files to yet another format, db3, to process with the software we used.
15 years later and things haven't changed. Although I support servers and operating systems now. No two software vendors implement the same technology the same way.
All that aside, the headerless CSV format that Garmin supports seems to me to be about the closest to a standard format. Depending the on the brand of GPS, you still may have to do some additional work.
Chuck - Nuvi 200, Nuvi 255W
Standards are good....
.... Chevy and Ford should have the same standard for engine displacement ... "ain't gonna happen!".
Not sure how a standard on displacement would help us consumers. Now a standard for fuel to be used, that would be a godsend to all travelers. Let's hope they see the value in that.
Oh - whups! They already did that! Never mind....
Not very helpful
Maybe instead of forcing Garmin users to step down to Magellan and Tom-Tom POIs, Magellan and Tom-Tom should step up and manufacture units compatible with more informative POIs.
Do you feel better now after venting??
I see this is going nowhere useful so I quit.
I feel obliged to point out,however, that a site like this is all about users helping each other.
Comments like yours in this thread do nothing to advance that goal.
Magellan Maestro 4250// MIO C310X
Give me more, not less
All that aside, the headerless CSV format that Garmin supports seems to me to be about the closest to a standard format. Depending on the brand of GPS, you still may have to do some additional work.
I respectfully disagree. I think with headers should be the minimum csv standard. With everyone using headers, every manufacturer's version of POILoader would be able to identify what is in which column and could import automatically without massaging and rearranging columns first.
That being said, I really think the standard should be GPX format, which allows many many extra fields of data to suit just about any user. Just as with HTML in web pages, sections of code or fields that are not supported by a particular manufacturer can simply be ignored during import. At the very least, a less sophisticated unit could identify the lat, long and description and ignore the rest while someone with bluetooth enabled dialing and bluetooth contact list transfer capabilities would get full use out of the extra data in the file.
Although I teased him a little bit, I agree with retiredtechnician. Why should those of us with better GPS's have to settle for the minimum "standard" of what the basic entry-level units will support? I say put the data in there, and let the cheapies ignore what they can't handle. Don't take away the extra data that I may want to use.
Useful?
I see this is going nowhere useful so I quit.
I feel obliged to point out,however, that a site like this is all about users helping each other.
Comments like yours in this thread do nothing to advance that goal.
Might I remind you this is a forum. A forum includes ideas and comments from many different viewpoints. Just because one doesn't agree with another viewpoint doesn't make it useless. If that was the case, I would have to make the same comment about your postings.
RT
"Internet: As Yogi Berra would say, "Don't believe 90% of what you read, and verify the other half."
Huh?
I respectfully disagree. I think with headers should be the minimum csv standard. With everyone using headers, every manufacturer's version of POILoader would be able to identify what is in which column and could import automatically without massaging and rearranging columns first.
I'm not exactly sure what you are disagreeing with. I didn't say what I think it should be, I only pointed out that the Garmin headerless CSV as being what seems to be the lowest common denominator, which for now is the closest thing we have to a "generic" POI file. Thats what the OP was asking about. Realistically, a "true" CSV has the header record.
Chuck - Nuvi 200, Nuvi 255W
Great Discussion - Now I Need...
OK, I have a headerless csv file with fields long, lat, text1, text2. No line breaks or line feeds, just straight text. It works great on Garmin.
What other brands is this file directly compatible with if any? For those that it's not compatible with what has to be done to make it compatible?
Generic POI
OK, I have a headerless csv file with fields long, lat, text1, text2. No line breaks or line feeds, just straight text.
If I understand you correctly, that is exactly what the recent Magellan's expect.
The comment about line breaks is a little confusing.
There must be a line break at the end each group of 4 fields; that is, each location on a line by itself.
Magellan Maestro 4250// MIO C310X
Have it your way!
I say put the data in there, and let the cheapies ignore what they can't handle. Don't take away the extra data that I may want to use.
Great. Perfect. Wonderful.
Just don't post a .csv file without an associated description indicating that it includes all that extra stuff.
Why is that so difficult?
Why would that be a burden on anybody?
It certainly looks to me like it would be helpful to many.
And if you want to be a REALLY nice guy, post both....with appropriate descriptions. A full file for the "ultimate GPS" users and a stripped file for newbies and the technically challenged.
Magellan Maestro 4250// MIO C310X
Line Breaks
Garmin allows line breaks in the text. Open POI Loader, Help, Creating Custion POI Files and Creating .CSV Files where they show an example and discuss line breaks.
Well Said!!!
If the manufacturers can't agree on a common format, be it csv or gpx, how are the users to agree? I sure don't believe I should have to reduce the capabilities of my Garmin POIs just because Magellan or Tom-Tom format aren't as inclusive; and, in return, I believe if I want to use Tom-Tom or Magellan POIs, I should be willing to convert and adjust them accordingly.
As with anything, 'confusing' is related to ones knowledge of that item. As you stated, Garmin "multi-line" formats aren't confusing if one is familar with them.
When we discovered the nuvi 350/360 had a problem displaying linebreaks, we didn't decided all GPS units should conform to our required <br> linebreaks. Instead, we worked on a solution and wrote a program to convert the linebreaks to our requirement. Maybe instead of forcing Garmin users to step down to Magellan and Tom-Tom POIs, Magellan and Tom-Tom should step up and manufacture units compatible with more informative POIs.
RT
I Agree 110%!
Tom
Standards
What I was trying to say about standards is this. Let's take a CSV file for a Garmin unit. We all know that it is Long, Lat, Name, Description. But not all of us put the same type of information into Name or Description. Many of us use br or " and some put in addresses differntly and therefore don't look the same on your GPS. I just think if there were a standard for how you put in the information, each POI would look the same. However, I doubt we could all come up with the best way to do it. For me, I don't like addresses that just wrap. I don't like seeing line breaks on my GPS (br), etc. Here's where standards come in.
Larry - Nuvi 680, Nuvi 1690, Nuvi 2797LMT
things
I see this is going nowhere useful so I quit.
Stick around! - this thread has six contributors so far--and at least six points of view
If the manufacturers can't agree on a common format, be it csv or gpx, how are the users to agree?
Manufacturers don't necessarily have anything to gain by agreeing, but users do! Maybe manufacturers will bow to pressure from their customers?
I just found out that Garmin's POI Loader silently ignores headers. It seems to just keep reading through the file until it encounters some data that look like plausible coordinates.
------------------------ Phil Hornby, Stockport, England ---------------------- http://GeePeeEx.com - Garmin POI Creation made easy »
Header lines in .csv files
Cool! I didn't realize that non-data lines would be ignored. Did you happen to test to see what POIedit does with a file like that?
What else would be nice, speaking of standards and things, is if a line with the first character of "*" (asterisk) would be treated as a comment line and ignored by POIedit and POIloader. That way, we could embed comments throughout the file for doc purposes without those aforementioned programs barking at us. Of course, the * is arbitrary - it can be any mutually agreed upon character.
"No misfortune is so bad that whining about it won't make it worse."
Headers
Quoted in part
I just found out that Garmin's POI Loader silently ignores headers. It seems to just keep reading through the file until it encounters some data that look like plausible coordinates.
With reference to headers, POI Verifier removed them when creating the _V.csv file as some programs barf on headers. One reason for POI Verifier was to try to make the standard Garmin csv format usuable in differenct GPS units. Some don't like linebreaks, POI Verifier has an option to remove them. Some require the <br> for linebreaks, POI Verifier has an option to convert them. Some require latitude before longitude, POI Verifier has an option to swap them ... and the list goes on. Is it really too much work to install and run POI Verifier to get the format your GPS unit requires?
RT
PS The new POI database that JM is providing already has multiple formats. This makes them adaptable to different GPS units.
"Internet: As Yogi Berra would say, "Don't believe 90% of what you read, and verify the other half."
New POI Database
"The new POI database that JM is providing already has multiple formats. This makes them adaptable to different GPS units."
Where can I find more information, how to use, etc?
Work in progress
"The new POI database that JM is providing already has multiple formats. This makes them adaptable to different GPS units."
Where can I find more information, how to use, etc?
Since this feature is 'Work in Progress', only some have this capability. An example is at:
http://www.poi-factory.com/node/6715
The user has the option of downloading a gpx, csv with regular linebreaks, csv with nuvi 350/360 linebreaks, or a csv with no linebreaks. Thank you, JM.
RT
"Internet: As Yogi Berra would say, "Don't believe 90% of what you read, and verify the other half."
POI Verifier
RT, you did a nice job with POI Verifier. I come from a mainframe computer background and comments in job control and elsewhere are practically required so that someone looking at the jobs could better understand what the job is trying to accomplish. I tested a .csv file with "comments" spread throughut the file and Verifier ended up correctly detecting/deleting/reporting them. Obviously, the comments must be BETWEEN entries to be detected/deleted/reported. If a comment occurs within an entry, it's taken as part of the entry. Anyway, I now have ways to document my POI's internally. Thanks.
"No misfortune is so bad that whining about it won't make it worse."
POIs Format on Garmin 750
I am using Custom POIs as I have not figured out how to "Group" things under favorites. I travel for work and have several addresses I travel to and would like to keep them separate from my personal addresses. The best I can do is create several custome POI CSV files. However even though I am using the very simple fromatting suggested in this thread My out put on the 750 is not correct. A sample line is:
-117.22316, 32.72570, "Holiday Inn San Diego","4875 N Harbor Drive, San Diego, CA, 92106"
The stree address repeats, 1st as large text like the name , then as small text which appears normal. Also, all of a sudden I started getting Alert information of distance and speed. How do I turn this off? Any help on any fronts?
Know problem
Add another character to the name. For instance, make the name "Holiday Inn San Diego." (Note the period) Reload the file and it'll display correctly.
"No misfortune is so bad that whining about it won't make it worse."
CVS not formatted correctly
Hi Phil,
Thanks. Tried it no diff except the period shows up in the name as well. My original CSV file displays correctly on my 350 but messed up on the 750. Go figure...
I have several lines typed exactly like my previous sample and I am getting mixed results. Some are perfect, some repeat.
POIs Format on Garmin 750
I had a lot of problems trying to get a csv to format correctly on my 750 when it contained quotes and comments within the quotes, not to mention line breaks.
What I did was to remove the commas within the quotes and then removed the quotes and it then displayed very nice on the 750.
I think city state zip is self evident without the quotes. I'm not suggesting this is ideal but rather that it provided a reasonalble solution.
.
I am using Custom POIs as I have not figured out how to "Group" things under favorites.
You can't categorize your Favorites.
I travel for work and have several addresses I travel to and would like to keep them separate from my personal addresses. The best I can do is create several custome POI CSV files. However even though I am using the very simple fromatting suggested in this thread My out put on the 750 is not correct. A sample line is:
-117.22316, 32.72570, "Holiday Inn San Diego","4875 N Harbor Drive, San Diego, CA, 92106"
The stree address repeats, 1st as large text like the name , then as small text which appears normal.
I believe this is related to the number of characters in the line. There was long long thread a few weeks ago where Retired Technician explained a work around. If you search, you should be able to find the thread.
Also, all of a sudden I started getting Alert information of distance and speed. How do I turn this off? Any help on any fronts?
This is usually because you have a number (1, 2, 3 etc) in the filename. Take the number out and you shouldn't get the alert unless you have loaded the alert some other way.
Minimum and Full would work
And if you want to be a REALLY nice guy, post both....with appropriate descriptions. A full file for the "ultimate GPS" users and a stripped file for newbies and the technically challenged.
Sounds like a workable plan, too. Bare minimum vs full-featured. I contributed one very small CSV so far, but in the future I think if I contribute something else I'll upload both CSV and GPX versions.
The idea of using header fields and ignoring what you don't want is the "standard" mind-set with many applications that have import/export capabilitles. So that is not a new concept at all.
Line Breaks in Your Data
I am using Custom POIs as I have not figured out how to "Group" things under favorites. I travel for work and have several addresses I travel to and would like to keep them separate from my personal addresses. The best I can do is create several custome POI CSV files. However even though I am using the very simple fromatting suggested in this thread My out put on the 750 is not correct. A sample line is:
-117.22316, 32.72570, "Holiday Inn San Diego","4875 N Harbor Drive, San Diego, CA, 92106"
The stree address repeats, 1st as large text like the name , then as small text which appears normal. Also, all of a sudden I started getting Alert information of distance and speed. How do I turn this off? Any help on any fronts?
With more work on my own data I now much better understand Garmins simple example with line breaks. For your data you don't need the quotes on field 3 since there are no commas. But the main thing you are missing is a line break in the fourth field. Your data should look like:
-117.22316, 32.72570, Holiday Inn San Diego,"4875 N Harbor Drive
San Diego, CA, 92106"
The above is one line to the line break after Drive followed by the second line. I mention this because it may display as 3 lines on POI Factory. Also you cannot see the line break after Drive.
There are various ways to get this depending upon which editor you use. I used Excel for my data but that is another subject.
Quotes in field 3
For Garmin csv POI file format, the quotes in field 3 do not cause a problem. In fact, the advantage of having field 3 enclosed in quotes is if you ever insert a comma, linebreak, etc in field 3, you are already prepared and will head off a possible format error in the POI file.
Linebreaks are not required in a csv POI file. They are optional.
RT
"Internet: As Yogi Berra would say, "Don't believe 90% of what you read, and verify the other half."
Agree I Think
For Garmin csv POI file format, the quotes in field 3 do not cause a problem. In fact, the advantage of having field 3 enclosed in quotes is if you ever insert a comma, linebreak, etc in field 3, you are already prepared and will head off a possible format error in the POI file.
Linebreaks are not required in a csv POI file. They are optional.
RT
I think you have to look at line breaks in the context of the data. While not "required" for field 4, if they are not used for address data the address may look odd on the Garmin. Or did I miss something?