Fishpool

To content | To menu | To search

Tag - Maemo Mapper

Entries feed - Comments feed

Friday 3 August 2007

Maemo Mapper and route quality

By Osma on Friday 3 August 2007, 16:42

Finally a comment about the navigation routes. This is not really about Maemo Mapper, because it simply displays routes from Google Maps, but nevertheless the suggestions have at times left something to be desired. How it directly relates to Mapper is in the way it might help make corrections to these routes require less manual effort.

Once the route instructed to leave a regional road to turn on a foot path shortcut; fortunately, this instruction was obviously impossible to follow. A second time the route changed from a steep but drivable hillside road to a dirt track a few kilometers later; perhaps it would have indeed taken us to the destination, but only with a 4WD vehicle, so we needed to backtrack and find another road, not necessarily a trivial exercise in the narrow one-way street Sintra region.

In both cases little could be done about the error at that moment, but it sure would be nice to be able to feed this information back to the route database. Surely the track information would be valuable to at least Open Street Maps if not also Google Maps. I've heard Navteq also use a similar mechanism to improve their own route databases from tracks recorded by users' navigation computers, and this collective track mapping for sure is the future for how navigation will develop.

Wednesday 1 August 2007

"Dad, are we there yet?"

By Osma on Wednesday 1 August 2007, 10:28

Maemo Mapper has a few displays in addition to the primary map information. It can overlay the map itself with routes, tracks, and points of information, and show the current speed as well as way-point directions over the map. It also has a secondary display of GPS position information, including altitude and compass.

However, it's missing a couple of critical displays; the distance to the next way-point as well as to the end of the route, and an estimated arrival time to the end of the route. The first two are simple to provide, and in fact are available through the menus, just not as a constantly displayed overlay. The third one can be tricky; the travel time may not be included in the route information, or it may be inaccurate. Estimating it from average speed is the other alternative, also vulnerable to errors when travel conditions change. However, providing some kind of estimate is still a useful service to the user.

The readability of the overlaid information is not quite ideal in the challenging in-car circumstances. The blue dot signifying current position is small on the high-resolution display, and difficult to see in sunlight. Making larger and animated (I would suggest a rotating symbol of some sort; keep in mind also the suggestion about scaling its size according to position accuracy estimate) would help. The speed indicator flickers; whether this is due to lack of double buffering or otherwise, it's distracting. Finally, the route direction dialog also changes shape about once per second, sometimes laying out the direction on one line, sometimes needing to place the last word on the next. Not surprisingly, this draws too much attention to it (hopefully not from the driver!) as well as requiring extra effort to read.

Tuesday 31 July 2007

Maemo Mapper map display and UI

By Osma on Tuesday 31 July 2007, 11:54

As a reflection of my previous description of a smarter way to download maps, I would also suggest that the display of the route would benefit from a slightly more automatic mode. The level of detail to display could well be chosen automatically based on a few parameters, such as current travel speed, distance from the next way-point, shape of the route ahead, and availability of detail maps. I realize the current design has preferred battery lifetime and has been limited by the hardware capabilities; however, these suggestions should not be greatly more demanding of the hardware.

A few such suggestions also come to mind; besides the semi-3D tilted map display I have read the author is considering, a "smooth zoom" function by map scaling would make the detail level selection a less jarring switch, especially when it was automatically chosen. In addition, at least this writer is challenged by having to read routes where the direction of travel is, for example, down-and-leftwards. Visualizing correct turn directions becomes an effort not always easy to afford while having to make quick decisions in traffic. The map doesn't need to be rotated in real time with 360 degrees of freedom to assist the user in these circumstances; simply turning it in 90 degree angles might be sufficient.

That is for how the display works; as far as how the program reacts to user input, a few small changes here and there might make also that better when considering that this is a program used while mobile and outside.

Tapping on the map currently centers the map on the point tapped, or if the tap is on a POI (or very close to it), brings up a small message box with the POI name in it. I would suggest to make tapping always perform the same actions; zoom in on the point tapped, and display POI or way-point data if available. Re-centering should be done instead by tap-dragging a point on the map; a function which currently behaves as if the screen had been tapped in the position where the drag ended and pen/finger was lifted, exactly the reverse of what such a gesture would be expected to mean (try it to understand what I mean).

Zooming out can also be supported; either by tapping on the center of the map (where instead of meaning "center and zoom in" it will mean "show more around this point") or if the tap-drag action covers a sufficiently large area of the display, zoom out to display both previously visible as well as the revealed area. This behavior has precedent in other applications, is quite predictable and easy to get used to (especially if the UI's feedback to the action is made richer by scaling up/down smoothly instead of a sudden 2x scale change. It should also be nicely forward compatible to a new mode if and when future tablets support multi-touch displays.

Downloading routes and maps in Maemo Mapper

By Osma on Tuesday 31 July 2007, 11:11

Maemo Mapper currently has three methods of downloading map data; the immediate, "show map of current area and detail level", and the two ahead-of-time modes, "download multiple detail levels of this region" and "download multiple detail levels along a route". The routes themselves are also downloaded over the Internet, from a gateway server performing a format translation.

The drawback of these methods is that along practically any route, especially one that takes the user through municipal areas as well as countryside or highways, any one fixed selection of detail levels is either going to be a big download and memory requirement, or leave the user with lack of detail in critical intersections.

I think it should be possible to improve from this accuracy while reducing the number of decisions the user is required to make. The route information contains a rich level of data about the general shape of the route. In particular, there are the way-points and the distance between them, and the route data on a turn-by-turn basis for display purposes.

Just by using the way-points, downloading detail maps on the way-points themselves, and a level of detail relative to the distance when between way-points, is this selection already made not just automatic, but also richer for the end user. By also utilizing the route shape data, detail level could also be increased when the route takes sharp turns.

Finally, if any points of interest fall close to the route chosen, it would make sense to download a more detailed map around that point.

If Mapper is used in the same area for an extensive period, it might benefit of keeping records of the tracks taken (with significantly lowered resolution), and utilize a similar logic to the above for also keeping detailed maps of the frequently visited places and nearby locations. Of course the user is already likely to be able to navigate in such an area without the help of extensive maps; perhaps this information could be augmented with data about where has she tried to access the maps.

Monday 30 July 2007

Maemo Mapper GPS position accuracy

By Osma on Monday 30 July 2007, 16:03

The first thing I noticed when enabling the GPS receiver with Maemo Mapper and walking about for a while, was that the track recording wasn't very useful if you're going in and out of buildings, subways, or similar obstructions.

When in a constrained space such as on a narrow alley or street with high buildings or when the receiver is just warming up, it's common for the position to jump around on the map quite a bit, with a messy result also in the recorded track. Since the GPS receiver can also give an indication of its positioning accuracy, Mapper should take this into account and not treat the position information on the same detail level. I would suggest that the display would show a lower accuracy position as a larger circle and move it only when the new position data falls outside the boundaries of this circle. This would also "average out" the error data in the track record.

Using Maemo Mapper

By Osma on Monday 30 July 2007, 15:31

As I mentioned previously, I bought a bluetooth GPS receiver for the trip so that traveling in Portugal wouldn't need to be a constant peering of maps. Since I feel much more comfortable with things I can tinker with, and because such an alternative to closed GPS software exists through Maemo Mapper, I chose not to purchase a commercial navigation software package at all.

For those unaware of it, Maemo Mapper is a program for the Nokia 770 and N800 Internet Tablets that interfaces with OpenStreetMaps, Google Maps and Virtual Earth to provide an Internet-connected map browsing and navigation package. It depends on (gateway-translated) Google Maps for route information, and otherwise functions by downloading maps to a memory card cache.

This is a pretty cool program, showing what might be the disruptive future for navigation and location guides in a cooperative, Internet-connected world. It's also one of the more usable applications for the Nokia platform. I wish the platform in general was as well designed for its primary purpose as Maemo Mapper is. If a way to share the track records and point of interest data with others is found, I feel this application might become a category definer. Great work by just one author, John Costigan.

We've spent the last week walking about in Lisbon, driving in the countryside hill roads, and navigating around in the Atlantic coast. While I've used Mapper on and off before to consult maps, on this trip, thanks to the GPS receiver, it's finally become a constant companion instead of a curious diversion. With this experience, I've also seen where it currently (in version 1.4) falls short of a perfect experience. As I write those findings down, I will post them here as suggestions.

Google Maps POI

I wrote a tiny Perl program to process Google Maps' new My Maps KML files to a Maemo Mapper POI database (download). This should probably be converted to Python to be easily installed to the tablet itself, but for now I simply ran it on my laptop and then transferred the database over.

one attachment