Suggestions Please!

1. What is around me, say a radius of a couple miles, or a selectable radius distance. Category is selectable.

2. What is ahead of me, along my route? Say within 1/4 mile corridor off the route. Selectable by category such as fuel, dining, lodging, and distance.

3. What are my closest POI?

4. Ease of setting proximity alerts.

5. Search by spelling POI.

6. Search by Category: dining, lodging, fuel, etc.

All of this is sort of out there already one way or another. The challenge for you is to make it extremely user friendly in a single simple app.

We have these great and enormous databases of POI, but how to use them quickly and simply has become the objective.

Diesel's #2 is a really big deal to me. It is quite frustrating to be on a trip and need gas and pull up POIs that are behind you or 20 miles to the side. Same thing with places to eat or hotels. If I'm trying to get somewhere, seeing things that are a major detour is just not helpful.

On the other hand, a notice when I am approaching a POI like a restrauant from a food network show I've downloaded the POI for would be neat, especially if it was close to meal time. I believe I can set the proximetry alert now but not one that only goes off when it's meal time and not one that knows my route and only goes off it it isn't too far out of the way.

If you wanted to get real fancy, you could incorporate a bluetooth link to the OBDII port and monitor gas usage. When I get around 1/4 tank (user selectable?) telling me I am X miles from the next Shell station (user preference for brand?) would also be really neat. If you incorporated a link to website information on price of gas to show that it would be fantastic.

You are right that there is a lot out there so I want to learn the best of all.

Rather than impose a structure, my thoughts here would be to build this where you would first define the categories that fit your needs. Perhaps there would be the catch-all categories like dining etc. already predefined. I would not provide POI's them selves, just the structure to organize them.

If you define a category named "Gas Stations" for instance then go on POI Factory and download a Chevron Stations file and import it into that category, It becomes a sub-category of POI points. You could also import Shell stations in to that same category as a second sub-category. You could also create your own sub-categories and import POI's to sub-sub-categories. It would be completely customizable to meet your needs.

You could select which categories sub-categories or sub-sub-categories to search and which would appear on the map. The search and mapping stuff is already built in my current prototype as well as the closest POI. I list the closest 100 points in distance order similar to Garmin.

The only truly challenging issue is the "What's ahead of me on my route." This may be better accomplished by viewing the pins on the map along your route since you can tap a pin for the info and tap "GO" right from the map.

I could also use a better understanding of how you all use proximity alerts. That is one area where my knowledge is lacking.

But #2 and 3 present different problems. You can only know what's ahead - or along your route if you have asked for a route to a destination. If this situation is present, then that should be the default search criteria. I would widen the search to as much as 3 miles either side of the route as a 1/4 mile will miss too many possibilities. This is an area Garmin performs poorly in as it has to be selected very early in the search process. The search currently is the 50 closest points to your current position as the default.

Setting of proximity alerts can be problematic. They can be set within a GPX file, but not in a CSV. Garmin allows a speed alert to be cobbled into a CSV by using the special charachter @ before a number but interpreting that is done in the loader processing.

Loading CSV and GPX files is also something to be considered. Would you store the raw file or would you parse the files creating a hybrid? As an example, 5600 lines in a 4 element CSV can be 600K but the same data in a GPX is 2M.

IOS for the pad and phone is not very forgiving as to the size of the app, so you have those considerations as well.

I drive 2,000 miles every fall to Laredo,Tx and then in the spring return, though quite often a different route home bound. Finding Diesel has never been a problem for me. I fill up every day around noon and am good until the next day noon about 600 miles later.

Just curious, if getting Diesel is a concern, why are you needing gas?

There is an iOS app called RoadAhead, that does look ahead on the road presently traveled and then presents services at the upcoming exits. It's pretty good, but could be better.

It does that function without navigating a route.

Michael, your app should be able to use the database from something such as CityNavigator, as well as POI files. And perhaps even use cell phone connectivity if it can/has to.

There are two basic proximity alerts available in the Garmin world, the along the route and one called a tour guide. Tour guide alerts function by creating a radius around a point and when the vehicle enters the circle, the alert is activated. The along the route or more properly the direction of travel, can best be envisioned as a rectangle with the location at the back center of end line which is about 50 meters in length. the length of the "box" is the distance the user sets as to the alert distance. With TourGuides, the radius equals the alert distance.

If an "along the route" location is more than 25 meters off the route, then the alert will not trigger. The exception depends on the alert distance or length of the box. While the POI may actually be on a different street the alert could trigger if the vehicle is pointed at the POI an enters "the box."

How they are used is something different. If you know the points would be off your route, but still close, you may use a TourGuide or radius alert. For something like gas stations, an along the route alert normally is sufficient because most of the driving is on the street passing by the station. Highway travel is different. For Travel plazas or truck stops, you may want a TourGuide radius alert because the aren't that close. So, the type of alert along with the proximity is highly personal and would be the end user's choice.

If you are going to use POI-Factory files as your customizable database, then you have to recognize the Garmin conventions for setting both speed and distances. You will also need to understand the field lengths of the data elements will vary greatly. The first two elements of a CSV will always be Longitude and Latitude with up to 6 decimal points of precision. In a CSV with 3 elements, the third element will be a text string that may have special characters to trigger the bluetooth dialing in a Tom-Tom. A Garmin will load either a 3 or 4 element CSV with the fourth element being another text string that either expands the information in the third or POI Name element or is a description of what is found at the location. Currently I think these two fields have a maximum length around 1024 characters, but they could be longer. With GPX being HTML, each element is described with its tag. GPX elements are not fixed as to the order of data elements so the entry has to be fully parsed and then assembled into a string you can use. A GPX file allows both a proximity and speed to be present for each individual point while with a CSV only the speed can be entered and that with the leading @.

Huh

This presents a potential solution to the "along the way" that would be somewhat of a compromise but might work. I could look at a radius circle or a box forward of the current heading to trigger alerts. The app could even run in the background while using other apps and still trigger alerts That is programmatically feasible.

As far as the GPX, I would utilize its XML schema to implement so that it is built correctly for any gpx file from any source as this is standardized.

My current waypoint structure already supports the csv. fields but I could use a reference on how the special characters work in various implementations. This could be more challenging because these are manufacturer customizations and not a standard. Is there any reference material on the site for these custom characters. I had noticed one or two mentions but I need something comprehensive.

I'm also still not clear on how the speed plays into alerts in practical application.

The help file for POI Loader gives the best explanation on how speed alerts are supposed to work. The file also gives you some keywords that trigger other actions such as a default proximity alert and cautions regarding TourGuide files. But you aren't emulating POI Loader so your app may not need the same caveats.

As to special characters used by Tom-Tom, I don't have one so will let others more familiar with that brand's formats fill you in.

I like exchanging routes with my computer - then those routes can be shared.

I don't just want "gas stations" along my route, but would like to filter based on those brands I prefer. Then, I would like to have price information available. Same with lodging.

Better routing. Garmin has too strong a preference for interstates and those routes can be longer and slower. Give me more than just "shorter" and "faster". Give me 5 different routes, show me the distance and time include traffic issues. Many times I find using state highways through small towns to be better routes for me than interstates through major cities.

A multi-variable search is needed, along with other perspectives.

Variables such as distance, direction from current or specified location, category such as dining, lodging, fuel, shopping, etc., spell a name (city), or must include a word or words.

So a search would have field options such as:

1. Distance: specify the distance from the location you are interested in.

2. Direction: specify the direction (ESE, North, 65º, etc) from the current location.

Note: this can also be used to search what is ahead. To search ahead, the app needs to know where it is and where the next waypoint is, then search pretty much a straight line between the two. The app will use waypoints as intermediate points for searching for POI along the way.

3. Category or Categories: specify the POI categories, such as lodging, dining, fuel, etc. Multiple categories are allowed.

4. Sub-categories are recommended, such as dining, fast-food or fine cuisine, motel or hotel, or gasoline, diesel, charging station, or CNG.

5. Brand preferences.

6. This search routine would use all installed POI files.

7. Map the search results.

What else?

You've all given me some great input and a lot of programming guidance but I think most of this can be accomplished. It looks to be about a two year build-out to get everything in place.

Phase 1 for me will be to integrate the .csv import and category building structure with Garmin's custom features included.

That will give me the platform and then I'll integrate the .gpx import for higher functionality.

Remember too that my goal is not to provide POI files but to build a tool to use with POIs from others such as this site.

Even Garmin cannot keep their POIs up to date so I'm not naïve enough to think I can.

To see how I plan to organize the base maps, category structure and navigation, you can look at http://gogalpublishing.com/home/State/PA/iPhone/PA_Fish_iPho...

This was my first POI based mapping and navigation app which has grown into a very useful tool for fishermen. The design will be the basis for this project. In this particular app, I do maintain the POIs which is a huge task as they include annual regulatory changes. You will probably recognize the design similarity to Garmin.

TWO YEARS!!!!!! WHAT???? I was hoping for next weekend.

What you are doing is what needs to be done. In the beginning, just having a POI file that compiled a list of whatever was an accomplishment. Now there are massive databases and compilations, and what is needed is an executive that can smartly mine and sift that huge database(s) to produce the correct search results. I was tempted to get an SDK to do this.

Good luck and thanks!!!!