Repost of the GPS navigation software ideas I had in 2007

About

This site is about a new PDA GPS navigation system called we-go. Why having another when there are already a lot? Read on...

Disadvantages of the existing navigation software

I started working on we-go because the existing software didn’t satisfy my needs:

• They cost money
• Their user interface is far from being user friendly
• They are mostly 2D even when they display it on the pseudo-3D perspective
• The maps get rarely updated
• No way to use bitmap maps (aerial map of the region - Google Maps) or if there is one, then the combination of vector and bitmap data on the same screen is not possible.

Key features of we-go

I think navigation software can be much better:

• It should be free
• Maps should be updated as frequently as possible
• 3D view is not a cool feature; it’s a visual aid for navigation. Think of a highway intersection where there can be even more than three lanes over each other. See how it’s displayed in pseudo-3D compared to the real 3D view.
• User interface should be skin-able to allow for customizing the user interface for each individual user. This is the most important for navigation software because it’s used during the intensive traffic and the time necessary to perform an operation should be minimized.
• Bitmap maps like those found in Google Maps could be layered over for even greater navigation hints.
• A desktop version of the program with all the features of the PDA version should be available (.NET can help with it) for managing the data, route pre-planning and transfer of the collected GPS data (see next topic) to the server.

Handicaps to jump over

The software itself is not enough to fulfill all the tasks of navigation. The data of different kind are as crucial as the software itself. Here are ideas where to get the missing data from:

• Maps. Usually maps are bought from Tele Atlas or NAVTEQ. Buying maps from them would not only violate the free software principal of we-go, but would not give large enough data update rate. In the case of we-go the data for the roads will come from the users driving on them. That’s not unique way to gather the road information, but that’s unique that everybody is contributing to the system not only the special teams of cartography trucks. This solution gives the cheapness of the maps together with the most frequent updates to the maps as possible. And I don’t need to pay for it. J
  As a side effect, collecting data of GPS positions of many cars allows us to find out the traffic lights rules: duration of each color, the ordering of green color switches on the same intersection.

• Height maps can be obtained from USGS GTOPO30. The resolution is about 1km, the missing details to be covered by collecting GPS data from end users. (Yes, GPS supplies you with the height from the see level information as well.)

• Bitmap maps can be downloaded from different sources including but not exclusively from Google Maps. Downloading from Google Maps can be online for users with internet in the car or offline - using the desktop version to retrieve the maps for the selected area or route.
• Collecting map by driving and recording the GPS data is not enough to know the street names and house numbers. There is got to be a way of specifying this information by users (if they want and can). So in the beginning we-go would not have any addresses available. And that’s the point: we will build the database of addresses unrelated to any authorities and regardless of any borders.
• There is a small relief as there is an open database of German city names and postcodes related to GPS coordinates at OpenGeoDB. This would be the first possible way of navigating where there is no street information collected. Similar databases can be available or obtained for other countries.

Code structure

• I imagine that the data for the final rendered picture should come asynchronously. This means that in the situation when CPU is busy with something, graphical engine may not have the height map information and would need to display the view in preudo-3D, but in the same time it ensures that the frame rate will not drop and the navigation will be interrupted leaving the user helpless as where to drive. In the current navigation systems this effect is especially annoying as the device tends to react sluggish especially on complicated intersections where navigation help is especially important. Another example could be missing road names or not yet loaded far roads which will be needed only later and not now. It also has a win on the startup time, as only little amount of data has to be loaded before the actual navigation starts.

• Currently the calculated route is defined once during route calculation and is only changed when the driver drives off the route. I would like to have we-go telling me on each crossing that there is another way which is maybe just 30 seconds (estimated) longer, but in my current road conditions will be preferable because of the traffic jam or just because this road has been driven by me too often and got boring.
• In relation with previous item we-go could detect that driving 5km/h or stopping on the highway means the traffic jam and would suggest the detour without being asked to do so. In other words it should be active and proactive.
• I imagine having 3D navigation window with the following layers (only some of them may be available at the time):
• 3D rough surface
• 3D detailed surface (may not cover the whole globe)
• Vector roads
• Vector road names
• Semitransparent aerial bitmap of the area
• Preplanned route
• Alternative routes with information how much slower they are (e.g.: +3:15 min, -1.2 km)
• Car position
• Actual GPS position (dot like in i-go)
• On top of the 3D view there can be several layers of 2D information and buttons (configurable with INI-file, BTW INI-file should be watched for changes, so that changes can be previewed without time-consuming restarting of the program). Simple information can be shown opaque near to the border:
• Time, date
• Current speed
• Current GPS location (less important)
• Maximum speed on that road
• Destination (I sometimes find myself following my navigation software with old or incorrect destination set)
• Time to destination
• Distance to destination
• GPS reception strength
• Compass
• Battery indicator
• Next turn or action (e.g.: turn left or enter the highway)
• Time to the next turn or action
• Distance to the next turn or action
• Clicking at upper right corner should minimize the software immediately (many PDAs are equipped with the cellular-phone or user needs to react on the event notification)
• Clicking anywhere else should bring the semi-transparent (!!! it allows to continue navigation even when buttons are visible) user-configurable set of mostly frequently used buttons like:
• Cancel route
• Turn off sound
• Start navigating somewhere else
• Enlarge/reduce the zoom (I prefer to use hardware buttons for this)
• Etc.
• BTW, regarding finding the navigation target: I think it’s worth having general input field for finding whether city, street name, POI name without specifying precisely what is it you are typing. This allows finding faster what you are looking for by typing first several letters of the name without clicking on the country, typing the city, typing the street or POI name only after that.
• The list of suggested destinations should not be sorted alphabetically, but should be sorted by the frequency this item was searched by specific user or all users (remember the global database) and size of the city. For example typing simply "f" should first show me Frankfurt am Main instead of hundreds of smaller villages (think of Google Suggest)

Technical details

• The code should be written in .NET
• The code should be shared between PC and PDA versions as much as possible (I can imagine that showing 3D display window can be much different on the PC and on PDA)
• The asynchronous data delivery classes should be named “suppliers”.
• All data should be stored in a database. I don’t want to invent the new file formats and write reader and writer classes for them. I know MS Access API exists already for .NET, but sqlite could be a faster solution, which, although, requires native code.
• Having database for everything really solves a lot of problems with data access methodology and speed (I suppose SQL-database is already optimized a lot for quick data access). This seamlessly allows for easy new data storage.
• We can use MySQL as free database for the huge online database of everything. Route analyzer-spider would crawl every submitted road from users to fill the gaps in the existing vector maps and detailed height maps.
• Once connection to the server is possible we-go would submit all collected raw GPS data to the server and download updated road information, height-map information, road names and whatever else gets updated. Having local database for storing the data simplifies finding out what has changed a lot as well as requires much less data to be transferred between the server and the client (it will not download the complete map of the changed city but really only the roads and POI that had changed or added).
• I think of having single version of we-go with all debugging functionality always enabled, but it is simply not visible for the users who just started using a system. It should be easily available if users want to get deeper into we-go.
• Commercial license should be available for companies willing to pre-install we-go on their hardware.

• I am looking for sponsors and donations as we-go doesn’t yet allow me to feed from itself. My fulltime dedication to the project would boost the speed of development a lot.
• Community support is the question of life-and-death for we-go.