Custom POI Standards

There should be a standard for POI files. I know not all brands use all the information. I know my Magellan 5310 cannot display anything other than the coords and the name so the address is useless on the GPS, but it does help a lot when looking at the file to see if the store by you is in the list or which is which if a location needs to be updated, or if you are traveling if there are any locations where you are going to.

I agree, I think it is time to have community standards. I will work on this and have some guidelines up soon.

Miss POI

Recently I have started including the city or a landmark in the name field. An example is "Houlihan's SF Airport", or Cosi-Fidelity Center. If I'm on a trip someplace, it does help to have an additional reference other than just the name Cosi, Panera Bread, or UNO Chicago Grill when you are searching for someplace.

Some of the large files, having over a 1000 lines will be difficult to update, but if we all work on them a little at a time, we can get the job done. The hard part will be keeping track of the changes to the larger files.

Thank you, that is great. Once the standard is developed then hopefully all custom POI's will begin to be formatted properly. Then as the old POI's are updated, they can be moved to the new format and eventually everything will follow the single standard.

Hopefully, this standard can be posted somewhere strategically on the site so POI developers can access it as a reference before submitting completed ones.

I realize it is a lot of work to create a detailed POI and it is nice to have access to all of them even the improperly formatted ones. I am glad that people take time to do all this work. However, it is probably better to have fewer properly formatted POi's than a lot of incomplete ones. Therefore, enforcing the standard will probably benefit everyone as we progress in the future.

Everyone will come to understand what is required for a custom POI and what the POI provides for them. The consistency will be very beneficial as we come to rely on these for information.

I just thought that it would be nice to have some way to identify the new POI's in the standard format without opening the spreadsheet and looking. Perhaps, by a naming scheme or separating the correct format from the others. Anyway, thanks for listening. I have a Quality background and I just thought standards and consistency would also be very useful in this area. The custom POI's available on this site are fabulous and a standardized format will make them even better.

Thank you!

bpa5152, I agree with you 100%. As the bad example of the day, no, as the bad example of the year, I would direct you to the Bahama Breeze POI. It's 49 records long, every one of them IDENTICAL, except for the longitude and latitude. Every entry says exactly the same thing: "Bahama Breeze." That's it. No city, no state, no phone number, no nothin'.
My first impulse was to say, "Well, at least the author tried," but then the more I thought about it, the more worthless the file seemed to be. Ah, well.

== End of Rant ==

I realize that it takes a lot of work to put information into a file, but here are a couple things that I have been looking and / doing on my files.

Column 3
I try and put city/state or store # information here. This allows me to search by name specifically if there are more than 50 showing at once. Also gives me an idea of what it is.

Column 4
It is nice to have the physcial address so if the coordinates are off, you can look for the address. When there is no address and the coordinates are wrong - you don't have any other options. A phone number is also helpful, especially for resturants. I try to eat at local places, and many of them in rural Kansas have different hours based on the time of year. It is nice to be able to call and check. Another piece of info that might be nice here is a verified/created date. It could give a "confidence" rating.

Daniel

This would be a terrific idea. But ...
If this refers to 'file structure', POI Verifier II already verifies per Garmin's requirements. When the new requirements are made known, I'll probably add another option for 'POI Factory' format requirements (if possible).

If this refers to correct coordinates according to addresses, how will it be implemented? Will it be left to the authors policing themselves? Can we count on that ... authors have already added _V on their file name to make it look like it was verified when it never was checked. Will Miss Poi check every file that is authored? Boy will she be busy! Should she set up a committee to put on a "confidence" rating? Will they only rate new files or go back to the archives and rate all POI files?

Are 5th fields going to be allowed? Not only does this go against Garmin's format requirements, some programs strip any fields over 4, including POI Loader and POI Verifier II; and then there are programs that just plain won't run when the field count exceeds 4.

It should be interesting. As a minimum, there should be some addition to the file name so we would have some indication which POIs conform to "Garmin's Standard" and which conform to "POI Factory's Standards"?

RT

Just popping in for a second to let you know that this is what Jon and I are focused on today.

Miss POI

col 1 coordinates
col 2 name
col 3 address (number, street, city, state, optional country) and phone number

everything else is gravy. thank you!

I believe you meant:

col 1 & 2 coordinates (Field 1=longitude; Field 2=latitude)
col 3 name
col 4 address (number, street, city, state, optional country) and phone number

RT

As I understand it, Garmin allows 4 columns of data. Does it make any sense to use column 4 for city and state (only) or some way in order to sort the data? The reason I ask is because in the past I have looked at custom POI files and tried to eliminate all coordinates except those in my city. For example I worked on the dog vet custom POI. This POI has thousands of lines of vets across the US and I only needed the ones in my city. Without city and state in a field of their own I had no easy way to sort them. Therefore, I had to go line my line and delete them which took hours. The reason I did not leave them all was because of excessive file space.

Any ideas on how to present this data in spreadsheet form that gives the users some flexibility to easily identify and eliminate those coordinates they don't need? Perhaps more columns could be required for this purpose even though Garmin only reads the first 4. Even though city and state can be in column 4, state abbreviation only could again be in column 5 to help everyone looking at these lengthy spreadsheets. That would also make sorting a breeze. I always look these files over before I load them in my Garmin and with the state buried in with the address it is hard to locate all the coordinates you are interested in. I also have a lot of custom POI's loaded so size becomes a factor. The opportunity to get rid of some I know I will never use is a worthy feature. Thanks

If you have POI Verifier II, it will create a POI file based on the coordinates for the state you select (sorry, it won't pull out by city). I noticed you have a nuvi 350. POI Verifier II will also change the linebreaks to the format required for the nuvi 350 (as well as several other nuvis).

RT

I have POI verifier II. When I tried to use it on the vet file, it didn't want to pull out the separate state data because of how all the address and city/state information was typed together. That is one of the reasons I pushed for standards in formatting.

The standard format development probably has to go beyond listing what goes in each column. There should be precise direction regarding each column so when the order of the address data is properly formatted and commas separate things properly then software like POI verifier II works when you need it to.

Don't you think if would be helpful to expand the columns slightly to help in understanding lengthy POI's and help those without the verifier software or will that be too great a burden on the original data entry?

I Live On the Border of the Province of Quebec and Ontario. We are separated from Ontario by a river (Ottawa river). When i open a poi file Ex: Shoppers drug mart the first one that appears is situated in Orleans across the Ottawa river. To get to that store I would have to drive 30 miles to Ottawa to cross the bridge and then drive back 30 miles. So here is my point in the 3'rd column we should always see the city name, and not just the store # or the address or whatever.As everybody knows, what shows up first is as the crow flies and not necessarily the closest. As for being able to sort and modify the poi file, if everyone put a comma between each field it would be very easy to use text to columns feature in Excel and sort by whatever field we want.

Ron
EX;
Col: 1 (45.484900)
Col: 2 (-75.501900)
Col: 3 (Shoppers Drug Mart - Midnight - 1675 Tenth Line Rd)
Col: 4 (1675 Tenth Line Rd, Orleans,On , K1E 3P6,
613-837-6078)

New One:

Col: 1 (45.484900)
Col: 2 (-75.501900)
Col: 3 (SDM- Midnight- Orleans (xxxx Shopping center))

Col: 4 (1675 Tenth Line Rd, Orleans,On , K1E 3P6,
613-837-6078)

The entry in Column 3 needs to be limited due to the number of characters that can be displayed when doing a search. In your example, and what I am doing in my POI is something like:

Col: 3 SDM- Orleans

While someone not from the area might not know this is not the closest store by driving, it does provide enough information that someone who had some familiarity with the area would know if it was a good choice. I think my Nuvi 200 only does something like 20 characters on a POI search line along with the distance. The entries for column 3 have to be tailored to the worst case and not the optimal. Column 4 can be formatted to put in line breaks.

For those of us just getting started in doing POIs having some standards and guidelines would REALLY help a lot.

Hopefully, a team of people can be comprised to compile everything a great custom POI should look like. Then the results can be put out there for folks to review and make suggestions.

Once a final format is agreed upon, I hope it can be presented and displayed in a manner that everyone knows this is the standard that must be followed to be worthy for this site and will be used for all POI's added, moving forward.

Hopefully, the older POI's will begin to move to the new standard as they are updated. This will provide consistency, and eliminate frustrations when trying to use the information provided on the POI.

This will also set an example for all other POI web sites and let them know Miss POI continues to have the best site out there and constantly strives for improvement.

For my 2 cents, there should be a standard regarding the State as well. Some use the Postal Standard of 2 letter State Abbreviation, some use the old 3 letter abbreviation, some spell out the entire state.

I agree with most of the rest of the posters regarding City and such.

A quick note to the person that commented regarding column width, when you are working with a CSV file format most of that is moot going between CSV and XLS. You can always widen the columns while working on editing it yourself.

Oh and another thing for standards, How about naming conventions for the File Names/POI Group Names.

I have found it difficult sometimes to verify if a POI exists using the Alphabetical Listing because of some of the Names of the files. How many can you have that start out with "THE"? Searches don't alwasy come up with the POI's and you have to double check the Alphabetical Listing. If the Names were more standardized it could make things easier to find existing POI files.

SOMEBODY opened up a can of worms when you mention Standards, but it is a good can of worms that needed to be opened.

OK, last one for a while, I swear.

After we have standards set up, it would be nice to be able to have two seperate Tracking Tabs for users. I would like to see a Tab of just the Files I have created. The more discussions you get into, the more your files become burried. If the discussions and files were seperated it would make life a little easier.

Thanks!!

I agree that there should probably be some minimum standards, but let's not make it too strict. Sometimes phone numbers aren't available, for example. Sometimes, there are not different names for the sites and store numbers aren't available on websites. If the standards become too severe, there will definitely be fewer POI files posted. Let's just be reasonable about setting "standards" and understand how much effort is put into most of these files.

I agree that they should not be to strict. Store number and Phone Numbers are not always available. However you should be able to include the City/State at a minimum. The bad examples are the POI's where it is just coordinates and the name of the chain.

I guess you could call it raising the bar, but not putting it to high to where it is un-obtainable.

Since I have family arriving this evening and staying until Saturday this topic will be tabled until next week.

Miss POI

I just ran a test on my Nuvi 200. The name field (column 3) is 18 characters before it truncates.

I agree Miss POI--you have a good idea. In the mean time what I do if I'm looking at a POI file like the Mall one mentioned, I use Microsoft Streets and Trips and enter the Lat and Long given and it takes me right to the location given, taking into account the sttings were correct as entered in the POI file. Also, if I'm altering POI files for my own personal use, I use the same method to check my entries. We all know that the Yahoo/Google settings occationally obtained from The GPS Visualizer Geocoder, we all seem to use, arn't exactly where they are supposed to be and if this is the case you can play around with the Lat/long figures a little to get the location where it is supposed to be.

Bob

Google and Yahoo often return a set of coordinates that match part of the address or the center of the zip code. Sometimes Google will match a street name to the name provided, but the name you wanted is slightly different - Greenpoint and you entered Green Point.

I'll often use the "Find local ..." in Yahoo to check the location is correct. I've had the geocoder give me East Main when the address is just Main. Often the source file, taken from a web site is wrong with misspelled street names, road instead of street or blvd. All this throws the batch programs for a loop and unless you check each address it's easy to miss these errors.

This is impossible because 'what is' or 'what is not' contained in Field 3 and field 4 has no bearing whatsoever on 'The Verifier' creating state files. POI Verifier II, as well as POI Verifier, creates state files based on the coordinates, and the coordinates only.

RT

Gonna need some exceptions! If one of the requirements will be to include the city AND state, what will the requirements be for POIs that aren't within city limits? Examples: Rest Areas and Fuel Stations along the interstate. Will they require miles from a city? Mile Markers? I don't envy your job, Miss POI. Sooooo many questions!!

RT

Quite true.

However in that instance it would still be useful to the users in your example to have the Highway amd State (I-65 KY, I-90 WI, etc)? I think the main thought is to avoid files with no indication of any location other then the coordinates.

I think that, by the voluntary nature of the POI-Factory project and the lack of a free and easy validation tool, we should look more at setting guidelines (Things that you SHOULD try to have) vs specifications (things that you MUST have). This way, we'll slowly improve all

Things I see that need to be discussed:

• What's the preferred format CSV vs GPX. - Coverage, should we go chainwide, nationwide, statewide/provincewide?
• What about different banners for a same store chain, should they be in different files?
• Character encoding (UTF-8 vs ANSI)
• Uniqueness of names
• Accented characters use and languages different than English
• Use of acronyms and abbreviations
• Formatting of NAMES IN ALL CAPS.
• Use of comments to track file version numbers, Data source, author contact info, etc

That's only a few things that pop to mind right now.

Given the number of files on the site, naming and sorting of the entries is becoming more and more important if we want the site to keep it's usefulness.

A simple example is the trip we took down the East coast last summer. This is unknown territory for me, so what better tool than a GPS to discover the sights. So I wanted to load in my GPSr all the POI files that would cover the area I was driving through but it was hard to do as not all entries clearly identify the states covered.

So, that's just my 2 cents, for now

Simon

I propose that spaces not be allowed in file names. It makes it harder to update poi files if your device does not allow spaces in file names.

I would also like to see the @ symbol added to the speed POI file for each entry. I am not sure how other GPS systems work, but Garmin will automatically add proximity alerts if files contain the "@" symbol before the speed. That way you know right away when you are going over the speed limit in a given area.

Yes, please Miss POI, if state is going to be a requirement, make that requirement to be the official Postal State/Province/Territory abbreviation. Then I can easily add that 'verify' option to POI Verifier II. Another question: What should be the requirement for POIs located outside the US and Canada?

RT

I believe you meant:

col 1 & 2 coordinates (Field 1=longitude; Field 2=latitude)
col 3 name
col 4 address (number, street, city, state, optional country) and phone number (if available!)

Well, if you're setting it on the table then I hope you'll try not to get gravy on it.

Mmmm, gravy.

Sorry.

That joke was a Turkey for sure!!!

How about we as a community name the new POI standard
The Melby Standard,once it is hammered out.

What better way do we have to pay homage to the POI-Factory Founders. Knowing that each and every POI on this site in the future will have a tagged file laying out The Melby Standard format, and will migrate it's format eventually to all POI files everywhere.

I bring this to our rank and file for consideration and ratification.

Do I hear any Motions

Great idea.

Daniel

I like the idea of the city name being included in column 3. As in, "Burger King-Redmond". Although including the city name sometimes might make the entry too long such as in my SEPTA.csv file where routes and station names are included in column 3.

Common abbreviations for street (st), boulavard (blvd), lane (ln), drive (dr), road (rd), avenue (ave), and maybe square (sq).

Tim

I just updated the only POI I've posted for the site. I made it the way I like to see a POI displayed.

Bakers - Hesperia, CA
12798 Main St
Hesperia, CA 92345
(760) 947-4388

I'd add hours but not all locations are the same.

One location doesn't have the address...even the corporate site does not list it so I listed that location as:

Bakers - Yucaipa, CA
Yucaipa Blvd at Ave. E near Interstate 10

At least getting the intersection will help since that location is on the corner and easy to see from the street.

I like to see the city/state in the name and a phone number in case I need to call. Hours are great for restaurants.

I will be hard and lengthy to get all these POIs updated to new standards...so many files and so many authors. Maybe an icon could show that they have been updated to new standards.

Different standards for different poi types? Just throwing out ideas.

Not that I don't appreciate all the dedication of Miss POI and Jon, but how about something funny and a wink to the whole community, like The Factory Standard...

Simon

I think I started a monster but I am glad I did. POIFactory is a great web site and the level of custom POI's provided and recommended should equal that greatness.

I have heard a lot of great ideas on creating the "best" format. Of course the format may vary slightly for those points of interest that don't have phone numbers or other applicable data. However, the end result is going to be outstanding and the overall quality of the new POI's generated have the potential to be significantly better and will provide more information with less frustration to the users.

I am anxious to see how this conversation continues after the holiday and I look forward to seeing the impact from all these excellent ideas. I would hope the ideal format is reasonable in the request for information an field placement. Keep in mind, it probably takes just as long to create a bad POI as it does to create a POI that best utilizes the GPS capabilities. After all, I believe one of the main reasons everyone participates on this site is to learn how to use their GPS to its maximum capability. Therefore, lets give it to them.

Great, now we get to name it. How about:

CPOI Code

CPOI Standard

Best POI Standard

CPOI Excellence

CPOI Design Code

Ha, how about "BPA POI Standard"

Since you all seem bent on calling this a "Standard." Will we need to follow the standards development procedure from ANSI? At the rate some of the standards I'm working on are written, it shouldn't take us more than about 3 to 5 years to develop the first draft.

We are so much better off revering to it as a Guide. Then we can have a Custom Point of Interest Guide - or CPOIG for short.

I believe if a standard is going to be created then the poi's have to be standard. if the Phone data is not known or does not exist then the equivalent of a blank variable has to input in it's place.

The Melby Standard to pay homage to the people that house the POI for us.

But that's part of the problem with a "Standard." Standards are by their very nature pretty inflexible documents. Guides are a lot more user friendly and the rules are not as strict. In this case, we can state the fourth column contains certain fields - street number, street name, city, state, zip, and telephone.

The Guide can state column 1 is the longitude of the point described in column 4. The longitude will have a minimum of 6 decimal places. Column 2 is the latitude of the point described in column 4. Latitude will have a minimum of 6 decimal places.

Column 3 is the name field. The name field is limited to 18 characters and should have as part of its content enough information to identify the name of the point of interest and an approximate location.

I agree, but getting into a "standard" would require each field be occupied with either the specified number of characters or padded with spaces. (Think of those printed forms with the little boxes for each character.) A guide would allow a field to be skipped and not be accounted for. And yes, Guides can and have become de facto standards.

I like this format. It's simple and easy to create

As I see it, any 'standard' file format has to be able to cater for the following requirements:-

1. Ease of creation, using existing software.
2. Support for multiple target GPSr systems (ie not just Garmin)
3. Customisable to the user's requirements, using existing software - on multiple platforms; ie not just Windows)

With that in mind, how about the following:

The file would be a multi-column csv file (with optional column headers). It would contain a minimum of three columns - Longitude,Latitude and Name. An optional 4th column (if present), would be the File Creator's preferred contents. This field would not necessarily meet any other person's requirements!

Additional fields may or may not be present, but if they are, they would be denoted by column headers. An agreed set of such headers would exist, but any arbitrary column could be included, if desired.

Given that Garmin's POILoader ignores column headers and columns beyond col. 4, the bulk of users would have access to a file that could be loaded without modification. Such a file could presumably be converted easily to other formats such as ov2 (either at the Server side, or on the user's system).

There may be other data present in the file, that allows the user (or POI-Factory server software), to build an entirely new file - to the user's requirements.

As a worked example:

I could upload a simple, 3 col. csv file containing a list of all the McDonald's in Alaska. Personally, I am not interested in any further data - as I believe I know everything there is to know about McDonald's )

-149.8535,61.2295,McDonalds
-148.5835,65.4479,McDonalds
-161.8235,67.2179,McDonalds


Another user may disagree and decide to add the telephone number. His own Züvi 925T can't dial phone numbers, so he just adds the information to the optional column 4. He is feeling lazy and presents this as arbitrary text - which displays OK for him.

-149.8535,61.2295,McDonalds,"Phone: 01234-5678"
-148.5835,65.4479,McDonalds,"Tel - 02 789(8) 345"
-161.8235,67.2179,McDonalds,"Ring, +1(2) 645, 3435"


A further user has a unit that can dial phone numbers and decides to modify the file, so that POI_Factory software scripts can generate unit-specific files, at some point in the future. In the meantime, he knows that some users will be able to manipulate the data themselves:

(He has to add column headers now, to signify what this new data is.)


Lon,Lat,Name,DEFAULT_TEXT,"Phone"
-149.8535,61.2295,McDonalds,"Phone: 01234-5678","012345678"
-148.5835,65.4479,McDonalds,"Tel 02 789(8) 345","027898345"
-161.8235,67.2179,McDonalds,"+1(2) 645, 3435","+126453435"


In this example, column headers "Lon", "Lat", "Name" and "Phone" would be part of a standard. The modifying user has no idea what Col 4. is supposed to mean and so assigns it an arbitrary name of "DEFAULT_TEXT".

In conclusion, the use of named, known, columns allows optional software to generate new files, that meet a particular user or unit's requirements without it having to try and parse free-form text. The presence of a lowest common denominator (4 cols), allows for a file that will work for most users, most of the time.

Discuss!

This is different than what we have now.......HOW??

Except for .csv being the "standard" format, the other stuff looks too loose to be considered a standard.

I kinda figured it would end up somewhere close to this. I think (almost) all of us can agree that .csv is best and LON, LAT and NAME need to be the first 3 fields.......that blasted 4th field is the problem.

Someone more familiar with the various loading and conversion software would be a better judge of this but I think F4 should contain: address city state zip phone......NOT seperated by commas.
Or maybe that should be fields 4 thru 8, seperated with commas. ?????