All posts tagged as "Location (LBS)"
user review: Droid vs Garmin for bicycle navigation
November 14, 2009 by Barbara
My father is a geek like me, though has been budget-conscious for my whole life. A few months ago, he started asking me a wide variety of questions of different types of devices he could use to fill his various needs, including bicycling and genealogical research in an area with highly spotty coverage. Numerous email exchanges later, we both decided on getting a Motorola Droid. He sent over this commentary on how it works for bicycling, partially to help another person in his device decision. I find the analysis fascinating. I hope you do, too.
I’ve experimented with using the various GPS Receiver functions of my new Motorola Droid toy. In short the Droid functions about as well as my Garmin eTrex in determining location but the Droid has limited navigation functionality when it is outside 3G coverage. Additionally the battery drain rate is high.
It appears that the Droid uses GPS satellites to determine its location for navigation type functions although it uses cell tower and WiFi data in conjunction with some apps.
Satellite acquisition and initial location determination
When I first turn on my Garmin it takes a couple of minutes to acquire satellites and calculate the current location. The unit “knows” where it was when it was turned off and has a catalog of satellites that it should see but it takes time to acquire those satellites and gather enough information to calculate location.
At home when I turn on Google Maps on the Droid it first shows a location based on cell tower data (I’m away from any known WiFi hotspots). It then quickly (less than 30 sec) zeros in on my house location. The impression is that the Maps App is much quicker in getting to the initial location than the eTrex. Ed. note: This is most likely due to the cell tower assistance.
I turned on the satellite view mode on Google Maps which shows aerial photography of my area. The blue dot showing my calculated location indicated that I was in the guest/sewing room rather than at my computer in the living room.
Tracking a bicycle ride
One of the apps tracks your movements. I assume that this uses GPS data and is not dependent on being connected to the network. I used this on a short ride that I believe includes areas that are out of coverage. I had the Droid in a handlebar bag and the Garmin mounted on the handlebar. On a 20 mile ride both units calculated the same moving time, distance and differed slightly on the altitude and total climb calculations.
I put the calculated tracks into Google Earth so that I could compare them side by side. Both tracks had errors. When compared to the rectified aerial photo I was all over the road and off the road for much of my ride. The Garmin seems to do a little better but that might be because it is set in a mode to attempt to follow the road. The errors were worse when I was in the trees. During one part of the ride the Droid seemed to have a consistent bias to the north of the road.
If I really cared about the accuracy I’d do some more tests with the Garmin set to ignore map information.
Navigating
I turned the navigation mode on for a 70 mile car trip home yesterday. The trip included a significant amount of time out of 3G coverage. I didn’t observe the navigation continuously but checked a couple of times when we were out of coverage. The screen was white, showed no map data, and showed that the app was doing a rerouting.
So as I expected you can only navigate when you are in range of the towers.
When it is navigating the default is to have the screen backlight on continuously. The Droid actually feels warm after awhile.
Also yesterday I unplugged the Droid around 6:30 AM. We did a round trip through low and no signal areas, I made a couple of phone calls, I also connected to a WiFi network and viewed various web sites, for about 2 1/2 hours I had the navigation mode in use. The GPS and WiFi receivers were on for the whole day. When I got home around 6:30 PM the phone was begging for a recharge.
Conclusion
No surprises. With the current apps the Droid will not replace my stand-alone GPSR. If they offer a capability to store map data and calculate routes on the device then maybe it could replace it. Since my intended uses include camping based bicycling trips I have recharging issues that would limit how I would use the Droid. For a trip that doesn’t include back country and has regular access to a USB power source it would probably be OK.
I am going to explore various off the grid recharging options such as solar cells and a new generator that runs off of body motion.
there’s location, and then there’s location
August 28, 2009 by Barbara
A few hours after we posted our location as context post last week, Twitter announced the same. With very different approaches.
I encourage you to go check out the Mashable discussion; many commenters are worried about opting out. Ignoring the problem of carelessly reading the announcement (maybe they just read the title?), there is a lot of concern about automatic tracking of location.
Few people, I believe, will want to live-stream to the world their location. Yes, of course many people will. But the over-30 woman typical of Twitter and Facebook? Probably not. Will she want to use location for their updates? Probably.
Location accuracy, precision, and comprehension
A quick primer: precision is the number of decimal places you measure something to; accuracy is how correct it is. The less accurate you think your measurement is, the less precise you should report it.
Read the blog post where this image comes from, and Steven complains about precision and accuracy at more length.
If you are a Verizon Blackberry user in a particular part of the Kansas City metro, your location is reported as what we believe is the actual tower location. A single tower in a warehouse area, not a triangulation of visible towers. Nevertheless, location in Google Latitude is reported as a single point. Very precise. Great for weather and maybe traffic; terrible for directions and geocaching. Location information is valuable at different accuracies, as long as we don't pretend it's precise.
Regardless of accuracy or precision, the usability of latitude/longitude information is terrible. It's useless to most people without a decoder, such as Google Maps. Nobody knows what 38.949984,-95.236038 is; many won't be able to tell you what hemisphere it is in. Actually, even Google doesn't know what it is, and provides only an address range. (Answer: approximately where my office desk is.)
So better than lat/long is an address (1901 Massachusetts St.) or a place name (Little Springs Design headquarters.) The preferred one depends on context. Sometimes absolute position is irrelevant, and only relative position is relevant (8 blocks south of downtown, or 3 blocks east of me.)
And many times absolute location is irrelevant, and only type or name of the location is relevant. And this is quite interesting for those commenters above. I don't mind telling the world I'm in a coffee shop, or in Starbucks, or a grocery store. Immediate family will know what city I'm in, and likely what physical place I'm in. Coworkers will know city and type of establishment. Family and friends far away will know type of establishment and maybe city. Strangers will know type of establishment only. We leverage the knowledge inside our network to provide privacy.
Some uses of location
These are largely social focused use.
Location as context
Location provides useful context to many status updates. Not geolocation; latitude and longitude require the reader to take several steps to understand the information being transmitted, and few will bother. Our discussion last week was for location as context; take a look at the Design For Mobile wiki page for explicit logic.
Many times location such as "Kansas City" provides absolutely no context. An update such as "Bad coffee day" is unexplained with a city as a context; it's very relevant with Starbucks or the office as a context. Which Starbucks? Which office? Nobody cares.
Latitude/longitude does not work for context. Too many steps for just better understanding context. Maybe some day there will be a single, easy-to-use solution, but I don't see anything likely on the horizon.
Automatic location does not work well for context. Which location? Henry's? Coffee Shop? Downtown? Lawrence? Kansas? One of those will likely be the appropriate context; the others won't make sense. And how does the machine decide? There's some theory, but I don't see it being easy and automatic.
Location for discovery
Based on the state of the blogosphere, many people believe that status updates to aid discovery will be big. They envision an augmented reality (or just a map) feed to see what is going on in a particular place. This could be useful, "It's dead in here. I'm heading out." could help somebody decide whether to enter an establishment.
I'm not sure this will be huge. Sure, it will be nice... in certain limited environments. Who is saying that it's dead? If it's my friend, I care. If it's a stranger, someone needs to build a whole other level of scarily-intrusive collaborative filtering to determine if you care. By myself, I've no idea whether it's relevant. And my friend is unlikely to be in that establishment. (I'd sure like to know if they are!)
Location as status
Work, home, kids' soccer, undefined. What if that was the entire list of locations? If the tool of your choice detected if you were in one of these, and set your status accordingly?
In this scenario, "undefined" is very interesting. This lack of data provides information, but only to people close to me. Office workers know I'm not at the office. My partner knows, based on the time of day and other information, that I am on my way home.
The inspiration for this was actually an automatic location system proposed at the Design For Mobile 2008 conference by Jared Benson of Punchcut. In particular, he noted that the human aspects of location comprehension.
Foursquare is attempting something like this, though its users are sometimes providing just city information and sometimes street address. But as best I can tell, the user must manually check in and out of locations. Somebody please advise how it actually works (the web site doesn't say.) Brightkite seems to work in much the same way, and I probably missed some more.
Location for...
Most of this post has focused on Facebook, Twitter, and social uses of location. However, there is a lot more available. Here are 47 location services ideas.
location based gaming and the next unexpected thing
April 10, 2009 by steven

Here's proof that the Design for Mobile conference is ahead of the curve. Last year one of the more interesting speakers was Swedish researcher Liselott Brunnberg. She showed off her Backseat Playground project, a game based on location, gesture (direction sensing, really) and using no output to the user but audio. And it worked; children are deeply engaged long into the test. Who doesn't want that for long drives?
Imagine my surprise and pleasure at this essay on the same concept by Jaako Kaidesoja, the Director of Games at Nokia. They are launching a social, location sensitive game and are therefore now pushing the whole concept to the developer community as well as presumably to consumers.
For more on Liselott's project check out an interview Barbara did with her, the summary of last year's session or the TII page on the project.
As we say a lot, GPS and gesture and almost everything else built into mobile devices are just enabling technologies. These sorta of locative media projects are exactly the sort of end uses that we can expect to emerge from this. I continue to be excited about the future, but now everyone else, go out and get excited also! I am almost disappointed in Jaako's essay, because it seems late to me.
There's no telling what the world will be like, except that it will be different and new. I'd love to see more encouragement from folks like Nokia to develop that next unpredictable thing.
There's still time to sign up for this year's Design for Mobile Conference. And if you can't make it to Lawrence in a week, or your training budget has been cut away, we've added inexpensive virtual sessions (sorry, not for the workshops) as well.
someone tell me how this is supposed to work
April 1, 2009 by steven
We’ve talked a lot about Nokia Point & Find; it’s a terrific example of how existing sensors can be used with networked data to provide contextually-relevant information without real (e.g. typing) user input.
And now it’s in beta. So first things this morning I install it onto my N95 8GB – their suggested device no less – and find out that it currently only really works for movie posters. So when I go for my run I make a point of heading to the movie theater (4 mile away). There’s probably a whole aside here about how I have not incidentally passed a movie poster in years, what with the multiplexes ripping theaters out of downtown walking districts, but whatever.

It’s indeed a beta. Not like Google’s eternal-beta thing, but it has bugs, uses astonishing amounts of memory, etc. And that’s fine, but… I still don’t get it. Either it’s just straight up broken or there’s something terribly wrong with the design. I guess it could be me, so if you got it to work, tell me exactly how, as their help documentation is a marketing brochure, and doesn’t say how to “just point and get information…”
The short version is that I pointed at several perfectly valid-looking posters, in different orientations, distances, lighting conditions. And nothing happened. Pressing OK jumped to this text-entry search for no clear reason.
It does indeed have some (UI) design issues. It’s not very Nokia, frankly. Odd softkey labels, a non-standard network selector, and the whole first run is baffling, with this signon to what thing, that ends up being a registration screen after all. Back is also both non-Nokia, and terrible, where it takes you to neutral states of the previous screen, instead of the literal back you’d expect.
I have great hopes, but sadly, am still waiting for a lot of these cool integrated apps to appear.
one pitfall (or two) of always-aware mobiles
December 9, 2008 by steven
And, I found some software that does neat stuff like this. I actually installed a bunch of location related software in the last few days and well... it's early. Some of the apps more or less don't work at all, and the rest are still a bit too hard to understand or use every day, or for less nerdy folks. But the future is clear and it'll be great soon enough. I have a half-dozen personal use cases for location based alarms.
A few days later I started noticing the N95s battery wouldn't last a whole day. Besides all the installing and playing , I have been doing a lot of testing for [a piece of client software] that I designed, so it was not surprising to burn down the battery. But then there was a weekend and it kept doing it.
Eventually, it occurred to me that it was one of those GPS items. I finally discovered how to turn off the always-on location awareness in the background, and it's fine. Yup, the GPS uses 3x as much power as usual.
Now, you could go ahead and take this to mean that it's not a good idea after all to run awareness software, or to run anything in the background (so the iPhone is right!), but I say these are totally surmountable instead, and addressing it head on is the only way to improve things. There are actually two problems, which both need (and probably already have) solutions:
- Awareness I installed them and am pretty aware of this technology, and it took me several days to figure out why my battery was dying. The problem is that there is no way to tell what is running in the background. The paradigm of always-on services is not different from current desktops, but the battery-powered, restricted processor and memory environment makes this more important on mobiles. The S60s running-apps list is something I have learned to rely on; I want to see a similar list of background processes, and a single way to turn them off, both for now, and forever.
- Power management Newer dedicated GPS devices can last almost 24 hours of on time. Sure, it has no radio and data processing, but they are using less exciting batteries, a large screen and can do this while running several "applications" at once (not to mention they get better reception than phones, and are spending a lot more power on DSP and other signal eeking). Running GPS-centric nav software will run down my phone in around 4 hours. Clearly there's a problem here of power management.
Now, the awareness products I was using went about twice as long, so there's something to be said for background process efficiency, but i suspect additional cheats would be easy. What about using tower ID (and maybe accelerometers) and only go turn on the GPS when the user is overtly moving? Then only poll the GPS for position only as needed. If nowhere near a location with an alarm, and moving slowly, check every minute or two. Faster and closer, check more often.
I can't wait to see even more stuff like this, and hope no one else gets scared off by all these challenges.
what convergence?
December 1, 2008 by steven
I have spent a fair bit of my time navigating. I've climbed mountains and hiked through wilderness for weeks with nothing but a compass and a map. I even teach navigation to ROTC cadets periodically.
When I finally succumbed to the GPS, I did some research but was overall pleased that – at least for the top brands – they abide by navigational standards. So they integrate nicely into the whole system. Which, with their propensity for minor failures, is a good thing.
For close to ten years I've been waiting for convergence to bring me a GPS in a phone. And for much of that time, after peripherally working on some of the systems myself, I've been instead waiting on a useful GPS in a phone. The N95, being a great device and noted as being good for GPS, made me excited about this again.
We've griped before about how location is not just GPS and maps (you can use towers, and use the data to make other services more contextual). But what I still find is that a GPS receiver still does not make a useful GPS unit in a phone. Sure, you get maps, but there are a stack of things that are just wrong with it. At least for someone like me.
Depending on how broken down I am, I run a couple times a week. And I use my Garmin GPS60 to track the time and distance, and tell where I am if I get lost. So this has been a baseline "useful GPS" test for some time. I did finally determine Nokia offers their Sports Tracker (although it's beta, so is not officially supported on many devices) which seemed to give speed, altitude, distance counters and so on so it might replicate the functions. So I took the phone for a run and tried it.
And it was pretty painful. Most of the experience was significantly sub-optimal, but let me try a few examples.
Where's the path?
Sports Tracker has no map. I mean, it has a path chart, sorta like older non-mapping GPS units, but there's no map data overlaid there. Maybe I was missing something, but it sure was easy to miss then.
So I tried Nokia Maps and Google Maps for Mobile. These all do, thankfully, run at the same time, so I was able to switch around between them to see what was happening. They still didn't help. I could tell where I was, but there was no track. The track on a GPS unit is a little dotted (usually) line showing where you've been. I like to keep them for years, so I can tell where the turnoff is to an obscure scenic outlook, and so on. For a local run, they have the same use. I can see old tracks and tell where the good (or bad) routes are, and I can backtrack if I went the wrong way.
This is a key feature for a GPS navigator, which is essentially entirely missing.
You are heading "right"
Standalone GPS units, and I guess mobile phone mapping software when route tracking, orient the map to your direction of travel. This is taken from real life, where a good way to walk around in the woods is to orient the map to your direction of travel; things ahead of you in the world are ahead of you in the map.
Orienting maps to the real world helps with mental models. It's called "mapping" even when no maps are involved; light switches should be "mapped" to their actual locations by relative location and orientation on the panel, and so on.
Disregarding Sports Tracker, which has no useful map (and if it did, it is still tiny) the two map nav programs I used orient north-as-up. Always. Again, I tried a lot of settings, but could not get them to switch over unless (sometimes) I was in route-following mode. And that was useless for two reasons: 1) route mode seems to insist on displaying in a cute 3D display, so the map is not really readable, and 2) I don't want to run a pre-planned route. I'd rather use paper.
Advantage: Garmin. They do indeed orient the maps north-as-up when you zoom out far enough (around the time the state takes up the whole screen). Below that, they automatically orient up as direction of travel. And there's no way to change this, because it's the right thing to do.
Waypoints, units and accuracy
There are three other features I use all the time on a GPS. The first is location. I very often want to know my actual location. Not as a point on a map, but as coordinates. Now, Sports Tracker does have this, but... not very usefully. For a lot of reasons I don't like lat/long (I use MGRS or UTM, and if you ask I'll tell you why) but even within lat/long, there are several ways to communicate it. DD.ddddd is only one of them; not being able to change it means I cannot really communicate with other nav devices.
An absolutely critical feature of every GPS is setting waypoints. You can do it before the trip to plan it, or do it on the fly. "Hey, a place that sells honey!" (this is real), then you mark it, label it at your convenience, etc. Absolutely no such feature seems to exist on any software I can find for any mobile. Yes, I should mention that Garmin and some others do offer software for mobiles, but it's so expensive that you can buy a cheap piece of actual hardware, so I don't know anyone who has it. I also just got to poke around with Sprint's navigator solution on a new Blackberry, and it has a sort of waypoint feature, but assigns a street address to each saved point; a sort of odd solution, that also misses the point of the coordinate systems above.
And lastly, there is another issue that is dear to my heart, precision and accuracy. Here, everyone is at some fault. GPS, like most electronic devices, implies great accuracy due to its display of data very precisely. But this is not true; only so much accuracy is available, and sometimes this is shown, but not robustly enough to me.
The Garmin unit, and some of the mobile phone software I have used has a precision circle, but all of it puts a very precise-looking center point, and (when available) displays coordinate location to many decimal places. I have been driving while others navigated incorrectly because a GPS (or more often, a phone) said we were a block, or a quarter mile, to the left. These devices need to work on ways to better visually imply they only have a certain amount of accuracy, and help avoid such use errors.
Read another blog post where I gripe about many of these same issues.
Datum and trust
I ran with both the GPS60 and the N95 running Sports Tracker on a couple of runs. At the end of the run I encountered one of my biggest concerns about this: they disagreed. See the image at the top of the posting. How is this possible? Well, I have some ideas, but they relate some to the issues with data above. There is no way to set (or even see) which datum is being used. This can mess with position indication, and position calculation. Sure, most users won't want to mess with it, but if the data is wrong, shouldn't there be some settings to let you try to fix it?
I want to be clear that I'm not hating on Nokia, or Google, or any specific product. In fact, these are finally good enough they are worth this sort of use and review. I don't even want to talk about trying a couple years ago to get a Nextel GPS to display useful data on the device. But this seems to be typical of far too many products that get "improved," or integrated (say, into mobiles). Core functions get lost or modified just a little, but enough to make them a lot less useful.
And I'd maybe gripe about how this could be fixed, but I do have hope it might get better on it's own. Camera phones used to be universally comically bad, but I might have bought my last point-and-shoot camera. Our current devices all have cameras as good as, and with more storage and easier transfer, than most standalone devices. Maybe I just need to wait another generation or two to see GPS – and other convergence features – that work in really useful ways. Or maybe they will always stay like this, as consumer driving navigators, and like my DSLR is the serious camera, standalone GPS will always be the serious navigator.



