My own Android running HTC Desire had to be returned to the manufacturer as it developed a fault; being a modern customer orientated firm, HTC declined to loan me a replacement and suggested I use another phone I had laying around. This seemed to be an opportunity to "eat my own dog food" and see what these work mobiles are really like. As tests go, this one is a bit out of date; the Milestone has been superseded by the Milestone2, which is itself not the most modern handset in the Motorola stable. It'll hopefully be interesting, however. This is not a review of Android, nor really of the phone in any sense that may be useful to anyone that was thinking of buying one, but more a collection of observations made about the handset.
We've had 150+ of these handsets for about a year now, the vast majority of which have survived a winter on British excavations with only some chipped paint and muddy keyboards to show for it.
The tested phone deserves some introduction, but that in turn requires an introduction into how we deal with broken handsets. In short, the phones are covered by a warranty and are returned for repair if they fail. The attrition rate has been reassuringly low, especially given the winter we've had on sites, but broken handsets have appeared and have been returned to the manufacturer. A number of conditions aren't covered by the warranty, however, and phones suffering this sort of damage (water ingress, for example) are kept back in the hope that something useful can be done with them at a later date. The phone I tested was originally returned from site with the glass screen severely cracked, not damage covered by warranty, which was repaired with the glass (the digitizer to give it it's full name) from a handset that had been written-off due to unfortunate water damage.
Fitting a new digitizer to a phone involves take the entire handset apart; according to this guide it's a "very difficult" procedure that frees the front of the phone by removing everything behind it. The water damaged donor phone is now in a box, separated into roughly a million pieces. Surprisingly, perhaps, the fixed phone worked fine once I'd finished screwing it back together. I was so chuffed with my success that I rescued it from the store cupboard as soon as I needed a loaner phone.
It's worth mentioning briefly that I use my (and my loan) mobile phone a lot. Calls, text messages, emails, games, music, photos, some more calls and some more text messages. The point is, I think I give these things a pretty thorough test.
Here are a number of points that I've noticed about the phone. Some are more important than others, with the least interesting at the top:
Is something you can hear when you speak. This is pretty weird to begin with, but I got used to it after a couple of calls.
Is pretty rubbish compared to HTC's custom affair. The Milestone uses the stock Android keyboard, which is improved in Android 2.2, but not so great in 2.1. Luckily there's that hardware keyboard, however.
My HTC doesn't have a physical button for the camera, which I used to think was a bad thing, but now I love my button-free life. The problem with the camera button on the Milestone is that it's incredibly sensitive and that it also cancels the alarm. When the alarm goes in the morning, for example, I often enjoy a couple of presses of the snooze button; with the camera button, however, I only have to tap it and I've cancelled the alarm. Picking the phone up in the morning to press the snooze button without accidentally touching the camera button is very difficult.
Locking the camera button to only camera duties would be a good thing
The Milestone has less computational grunt than my HTC does, which is evident when using the handset. Everything works ok, it's just not as responsive as I have been used to. I installed Advanced Task Killer on the handset to try and improve performance after using a particularly heavy app. Some things, such as opening a large web page, or listening to music, can suffer if you've recently had a number of other items open. At this point, freeing some memory works well and is the only time I bother with a Task Killer.
The phone should connect to nearby remembered WiFi networks when it comes out of sleep; this is something it often fails to do, however, requiring a manual poke to get it connected. I think this is something it's failing to do at a WiFi level rather than higher up the network stack.
This is something I've been pleasantly surprised by; in areas of marginal signal the Milestone is much happier to call and text than my HTC is. I'm seeing improved call quality as a result.
I've been very impressed with the battery life of the phone; despite heavy use it will also last the time it takes me to get out of bed in the morning and back into it the following evening. It gets charged whilst I'm asleep and never needs a top-up. I have noticed that the battery indicator will sometimes suddenly drop to a fantastically low level, alerting you that the phone needs to be charged as less than 10% battery remains. I am confident, however, that this remains a problem with the battery life reporter, rather than the level of juice in the unit itself; plugging the phone into charge for a second will restore the reported level of power back to its previous level and you can keep using the phone without worrying. If the underlying battery reporting subsystem is faulty, as I suspect, all battery monitoring applications and widgets are going to be useless and should be avoided. I have not been using a task killer application to try and extend battery life.
If anyone has a phone with what they think is a poor battery, I'll be more than happy to swap it for this one, it works fine
The Milestone has an annoying habit with which it appears as if the handset is dropping calls; in reality, however, it's just very easy to put people on hold. The proximity sensor in the phone doesn't always work as well as it could do and at times it mistakenly thinks that it is away from your face. At this point, you can use your ear to push any of the buttons displayed on the screen; one of which puts the caller on hold. Suddenly you can hear them, but they can't hear you, which usually leads them to hang up before you can un-hold them. Explaining to people, however, that this happens and that you need a moment to take people off hold before they hang up, usually fixes this problem.
Opening the slide mechanism whilst in a call, if only a tiny amount, will have the same effect; the lesson here is to not fiddle with the phone when using it.
In the almost two weeks I had the phone I was pretty pleased with it; it generally worked just the same as any other Android phone, just a little bit slower. The physical keyboard is great, as is the signal sensitivity, and there's only a couple of slight niggles to get used to. I'm surprised that the phone is as physically robust as it is and that it can work after I taken two apart and put one back together. It's quite a bit phone that can appear a bit clunky, but it seems to work very well.
I've not blogged in a while, so here's some links to new and updated guides from OA (North), hosted on our Library site:
Enjoy and please give us feedback if you've got any.
4 days before the release of 10.10.10, but I hope this stays relevant after the next release...
If you want to get MP3s from the Amazon store you need to use their MP3 downloader, which has been built for Ubuntu 9.04 and isn't explicitly future compatible. The app wants libboost-*1.34.0, whereas 10.04 comes with 1.40.
To get it working on 10.04 I followed the instructions here:
wget https://launchpadlibrarian.net/26959932/libboost-signals1.34.1_1.34.1-16ubuntu1_i386.deb https://launchpadlibrarian.net/26959936/libboost-thread1.34.1_1.34.1-16ubuntu1_i386.deb https://launchpadlibrarian.net/26959922/libboost-iostreams1.34.1_1.34.1-16ubuntu1_i386.deb https://launchpadlibrarian.net/26959918/libboost-filesystem1.34.1_1.34.1-16ubuntu1_i386.deb https://launchpadlibrarian.net/26959916/libboost-date-time1.34.1_1.34.1-16ubuntu1_i386.deb https://launchpadlibrarian.net/26959928/libboost-regex1.34.1_1.34.1-16ubuntu1_i386.deb https://launchpadlibrarian.net/34165098/libicu40_4.0.1-2ubuntu2_i386.deb
sudo dpkg -i *.deb
rm -r old_boost
This installs the old libboost as required by the app. I then apt-get installed libglademm-2.4-1c2a and the downloader worked fine. Which is good, because then I could listen to the very enjoyable Ninja Tune label sampler. Well worth the effort.
Introduction: Location Aware Games
Since recently getting my new HTC Desire I've been quite impressed with a little location aware game called The Great Land Grab and by the looks of it I'm not the only person. The game is pretty simple; you load it up and you're presented with a Google Maps view with your location displayed, also shown is an overlain grid of parcels that are each individually priced. Moving to a parcel gives you the opportunity to buy it, this costs money, but also earns you rent. The more often a parcel is bought, the higher the price of it and the higher the return. There's a bit more to it than that, but essentially you move around buying parcels, some more often bough than others.
I started thinking about the data collected by this. Apart from some simple user stats, there's not much we as users can look at; presumably, however, the game developers query for the most expensive parcels to see where most game users are. Plotting the price of parcels for a large region, the UK for example, would produce an interesting map of gamers' locations. Animate this into some depiction of a period of time and you might have something really interesting.
That's great for the people behind the game, but I wondered if we could produce a game that would get people contributing to OpenStreetMap whilst ostensibly doing nothing more than playing a fun game. I came up with a quick specification of what an OpenStreetMap game must be:
- Fun as a game in its own right
- At first glance nothing to do with open spatial data
- A means of contributing new data, or preferably, validating existing OSM data
Such a game could (and should) take a number of forms. In effect all we're doing is taking the same location aware ideas that lie behind The Great Land Grab and providing the data to a non-gaming community for the purpose of improving OSM. We'll need to include a disclaimer explaining that, but the game should be enjoyable without thinking about the improvements you're making to the map. In a perfect world you'd play not even knowing OpenStreetMap existed.
My game proposal: Droidenteering
This game presents no map display to the player but sets a number of challenges to be completed. Challenges are comprised of finding a number of things within the real world; 10 pubs, for example, or 5 supermarkets.
Players could have running a number of challenges at a time, up to 5 or 10 perhaps, and would progress through each challenge when completed. A first challenge may be to find a single pub, or supermarket or bike shop; completing this challenge then moves you to the next level, upon which you have to find more examples. Players are judged on the speed at which they can find the required level of features and also how much information they can provide about it. This would all go into an online scoring system.
I picture it working something like this:
Player starts the game and is told they need to find 10 pubs, 3 of which they may have already found. "Finding" a pub means getting as close to it as possible and clicking the "feature found" button; a lookup is performed to see if this is already in the OSM database, if it is the pub's name is returned and you are asked to confirm that you are outside it. If the feature is not found, you are asked to enter the name of it. Either action would be enough to qualify it as found, leaving the user free to find the next pub. Extra points would be awarded, however, for adding details such as house number, road name, telephone number, food details, etc. Each type of feature being searched for would have their own possible fields for entry.
You could cheat this by going to the middle of nowhere, saying you've found a pub, and moving on, but the game would include a validity score to check that other players were finding the same thing. Players would check online to see their progress against others and would aim to find features the quickest, or to earn the most points through the level of information provided. Weekly challenges may be presented to see who could find the most topically relevant features of the moment. Special awards could also be given for a whole range of arbitrary achievements.
Feeding this into OSM, and back to the game
Whilst players are running around collecting features to earn points, the data would be collected and entered into OSM on a regular basis. The same validity score that is used to check the correctness of data; if you see 10 dots on the map for a new pub found by 10 unique users you could be fairly confident in adding that POI to OSM. Hopefully one or two of the players would have entered as much metadata as possible to make the POI as rich as possible. Once entered into OSM, this would give feedback to future players, possibly with the option of reporting spurious features from within the game.
Last December I worked out that about 39% of UK pubs were on OSM. Such a game as suggested above could help rapidly improve this figure. Whilst I've been typing about pubs, the same could be said of any feature. At any one point a player would have in mind a number of POIs that need to be found to move onto the next particular challenge. Whilst they do that, a group of volunteers could check the submitted data and add it straight to OSM.
Beyond The Map
Apart from The Map, there are precious few ways of interacting with OpenStreetMap data. The proposal above gives the data a value to people who are interested in being outside, rather than those interested in Free spatial data. By implicitly appealing to a wider audience, gamers in this instance, we can collect user data that can directly feedback into the project. This is just one example, but I suggest that we need many such initiatives to get a broad spectrum of people and their data into the World's finest data source.
Cameron Shorter sends word through the OS Geo discuss list about this video of his great recent talk at the International Federation of Surveyors conference earilier in the week. Anna's survey and GIS manual gets a good plug, as does OA more generally.
Well worth a watch if you're into surveying and want a round up of current Open Source tools available to you.
Two videos produced as a result of our work in Multiple View 3D reconstructions are now online:
And for those of you with Red / Cyan 3D glasses:
See our fledgling YouTube Channel for more (including full HD):
My two recent favourite videos about the potential of Open spatial data and tools. If you're interested in maps, GIS, spatial things, etc, they're definitely worth your time (less than 15 minutes combined):
Further details on our Open Archaeology site:
There's currently an impressive OpenStreetMap tidy-up effort quietly happening across the globe, you can read about it here. Of course, duplicate nodes aren't the only sort of messy data possible to see on OpenStreetMap, but it's a good place to start if you want to help improve the quality of data within the database. Personally, I'm most interested in mapping Africa, so I'm always keen to see how many red crosses are on this view. As it happens, we can look at how this tidy-up, and others, have impacted the quality of OSM data by trying to plot a route with CloudMade across the continent, but first some more introduction.
Mapping in Africa was given a fantastic boost relatively recently by Robert Soden at Development Seed when he was responsible for importing over a hundred thousand miles of Africover road data into OSM. Obviously this is absolutely fantastic, but I was finding that when clearing up dupe nodes, and looking at aerial imagery, that the Africover data was particularly liable to errors and broken segments. This isn't really a problem; OSM is a wiki and we're all able to tidy up this data - think of these roads as stubs and we've got an amazing starting point from which to build a free map of the continent. Tidying Africover data, and ways sourced from elsewhere, I began to think that it must be possible to measure improvements made to the map. The thinking is simple: You plot a route from A to B, the produced route isn't perfect but you note the calculated distance; you then improve the data and the route between A and B becomes shorter as the software you use doesn't have to route around errors and can plot a more direct route.
Such thinking isn't exactly new; people have long been using routing applications to test the quality of OSM data. You can do it now - try entering your home and your place of work into a routing application and seeing if it comes up with the way that you actually travel. If not, you might go home a funny way, or OSM might have some incorrect data about your part of the world. Regardless, if you record the same route at intervals across a period of time and you could start to judge how the OSM data in a region is changing.
With that thought in mind I was very pleased to revisit an old blog post at 27 Months that spoke of routing from Cape Town to Ethiopia; most importantly it contained a screenshot (reproduced below as I didn't want to leech anyone's bandwidth) and a link defining the start and end point. All we have to do is click the link and compare the results:
In August 2009 the routed distance is recorded as 7298 km, taking in the south west and central countries of Botswana and Namibia; by March 2010, the route had shrunk to 6666 km and travelled south through Zimbabwe. This seems to show a great improvement in the quality of road data for south east Africa; as the recorded roads get more complete and contain less errors, shorter routes can be plotted along them. CloudMade allow you to download the route as a GPX file; a potentially very useful record of the state of OSM data. Also, note that in the first image you can read Zaire, something Wikipedia tells me hasn't existed since 1997; a further indicator that data improves over time.
The above image shows us that we should perhaps be careful; shown on the map is a route from Morocco to Algeria, although the guide books tell us that this border crossing is closed. At least the data can be easily changed, however, and routing services used to check the accuracy.
Good news all round then I think: Routing services can be used to provide an analysis of OSM data over time (as long as you can find historic examples), it seems to be improving and, if errors remain, routing tools can be used to improve and verify road information across an entire continent. Whilst I've only demonstrated the concept here, if we compare regularly generated GPX files from CloudMade at some point in the future, we will likely be able to say a great deal about road coverage in the region; continuing to look at this in the future may reveal insights into the ongoing efforts to map Africa or elsewhere.
Very sad news from the pages of Rolling Stone:
Singer, songwriter and multi-instrumentalist Mark Linkous has committed suicide, his publicist confirms to Rolling Stone. Best known for his acclaimed work with Sparklehorse, who released four albums of imaginative ambient psych-folk, Linkous also produced Daniel Johnston’s 2003 album Fear Yourself and collaborated with Danger Mouse on Dark Night of the Soul.
Sparklehorse defined great swathes of the music I listened to in the last decade; I have memories of consciously thinking that I would write specific essays for my MA to read something like the band sounded. The Rolling Stone write-up is pretty good, and has plenty of links to further reading. I was also pleased to see the story made the BBC.
For more information, see the Project Haiti wiki page.
Ben has announced to the gvSIG mailing list the availabilty of the second beta of our OA Digital version of gvSIG.
More details on our site
From the site:
Advantages of gvSIG OADE 2010
GvSIG OADE 2010 differs from the official gvSIG 1.9 release in the following respects:
* Completely new installer frontend.
* Comes bundled with many extensions.
* Includes Java Runtime Environment version 1.6r17 (Linux and Windows versions only).
* Complete and consistent English (GB, US) GUI translation.
* Heavily reworked and improved menu structure, keyboard shortcuts and layer context menus.
* Additional documentation and sample data.
* Better integration into all supported operating systems.
We hope that you will enjoy what we did with gvSIG!
Changes in gvSIG OADE Beta 2
* Improved labels and formatting in raster layer legends.
* Added some useful raster colour tables for elevation, slope, aspect and more.
* Corrected placement of affinely transformed layers.
* Added DWG CAD format support.
* Fixed a number of bugs that would cause crashes in the raster and remote sensing tools.
* Export of maps with advanced labels to PDF no longer crashes.
* Added missing symbols and label styles.
* Proper file type descriptions in all file selection dialogs.
* Unified native binaries: all versions use GDAL 1.6.3 and PROJ.4 version 4.7.0 now.
* Runs on Windows 7 (but see notes at end of this page!).
* Improved Windows startup performance: no more copying of large binary files on startup, no more write access required to installation folder.
* Updated Java runtime environment (JRE) to latest 1.6u18.
* Some translation fixes.
* Updated North Carolina sample data project to gvSIG 1.9 format.
Yann might be unhappy with Google and their new Buzz service, but I'd like to play with it some more and see how it pans out. Add me if you want to.
I've got a Google profile and, of course, an address: iknowjoseph at gmail dot com
Let's see if I can get more social... ;-)
Thanks to some new lab settings:
I'm sure that the geofolks will have already been all over this, but I like it. Enough to replace OpenStreetMap though? Probably not.