The Spatial Miscellany

This post builds on a previous post from earlier in the week, when I gave mention to some Nokia\Apache software that runs as a mobile web server on my mobile phone (a Nokia N95). The first thing that jumped out was the architecture of the software, ‘software above the level of a single device’ as coined by Tim O’Reilly. Then Phil jumped in with a comment agreeing with O’Reilly that such software has the potential to simplify the user interface of devices with small screens, but there is more to this software. A Google blog search revealed Ricky Cadden asking the same question…”I think there’s some serious potential here [MWS], though I can’t quite put my finger on it”.

Here is one reason I think it’s a real game changer – it completely removes the necessity of a network operator?

The likes of Skype and Gizmo already threaten the network operators’ phone call revenues, with VOIP based services; the mobile web server goes further. Let’s assume all mobile phones run with a mobile web server and have access to a wireless internet connection. Now write a one sentence webpage and host it on your mobile web server; restrict permission to view that web page to your best pal; make a request against a web service, running on your friend’s mobile web server, that alerts them of the new page you’ve created; and essentially you’ve just sent a text message – but without the network operator.

Moreover, replacement of the 160 character text message is only the beginning, this is revolutionary technology and a whole host of innovative applications can be expected to follow. What form might they take?

If we do move to a situation where the world’s 3 billion mobile devices ship configured as web servers, it would represent at least a doubling in the size of the internet (if there is a suitable metric by which to make such a measurement). What is more, if recent trends continue, and phones are equipped with GPS, these new web servers will be location aware and mobile.

There will be a live webcast of the Geospatial Web Services workshop held at the University of Nottingham today:

http://www.nottingham.ac.uk/geography/geowebservices/

Last month saw the annual event that is [Where 2.0], a conference hosted by O’Reilly in San Francisco. Over the past couple of years it’s been somewhat of a landmark event in the geospatial calendar, often playing host to a raft of new and exciting location aware technology…Woodstock for Neogeography?

I’ve never managed to attend the conference, but always made a conscious effort to follow online; this year it felt different, no headline announcements or cool new products, and very little chatter.

One announcement that did grab my attention was made by John Hanke from Google during the ESRI\Google keynote (you can watch the keynote here). Hanke remarks that Google have provided access, via their search API’s, to the Google ‘GeoIndex’ – an index of results returned by Google robots as they crawl the web for geospatial content. On the surface, this is significant news, but it seems to have received only little comment.

Hanke suggests the Google search API’s will provide access to the “content, attribution, linkbacks and the urls” that make the geoweb…but where are the underlying resources, where are the KML files?

Barry Hunter has knocked up a useful php script that queries the GeoIndex and nicely formats the JSON response. Try it out and you’ll notice you get a handful of Google Maps url’s, but no links to the underlying resources? Hopefully, there is more to come; providing access to the GeoIndex, and the underlying content files, really would move the ‘geoweb’ forward.

Last week Google announced an umbrella API for social networks, OpenSocial. On the back of their announcement, Google have released a preview of their API. Thumbing through the API preview I expected to see some elementary support for location, perhaps a “city” or “hometown” tag that developers could geocode, so I was pleasantly surprised to find what appears to be another implementation of GeoRSS…

I recently shared a few beers with an old university lecturer. We noted the ever improving access to the excellent Ordnance Survey mapping data but tongue in cheek he pondered…

“Is the writing on the wall for the OS grid reference?”

Here is a guest post from University of Edinburgh GIS lecturer, Bruce Gittings…

---

I see multimap have become the first to offer OS data on a slippy map
interface to a web service.

The writing is certainly on the wall for anyone contemplating a system which isn’t slippy – - that’s now the benchmark, anything else is dead technology. We’ve known space is continuous for a few years now and the average GIS toolkit gave up on ‘coverages’ and ’tiles’ a while back.

At the same time multimap also seem to have moved to using latitude and longitude, instead of eastings / northings on the national grid, probably as a function of the software they are using. The map is actually skewed to the window – most unusual. So, as more and more applications want WGS84 / GPS compatibility will the OS grid reference disappear? For decades this has been the de facto (indeed virtually the only) referencing system use for locating places on maps in the UK (excepting one-off grid systems used on town plans for example), despite a lat-long grid appearing subtly on the edge of OS sheets. Yet, the dash to lat-long driven my pan-national web services seems to be quickly moving the amateur place-referencer quickly towards lat-long too, if the dreaded wikipedia is anything to go by (wash my mouth out with soap for mentioning that word!). I wonder if they realise the implications?

There’s a lot more misunderstanding about lat-long than the good old simplicity-itself national grid. The oft-used precision (e.g.
55.12345678901234556 degrees north) – just because the computer can calculate to that number of decimal places – takes positioning to a ridiculous sub-atomic level. Even multimap – who should know better – have fallen into that trap. Also, most people don’t understand it is not possible to convert between lat-long and eastings/northings terribly accurately, and that, unlike eastings and northings, two numerically identical lat-long positions don’t necessarily refer to the same point. But let’s not pretend I’m a mathematical whizz who actually understands coordinate systems and transformations, but its all here if you want the details: A guide to coordinate systems in Great Britain.

But all of that only slightly undermines multimap’s achievement. I wonder if they had to get special permission from the OS to use their data in this way? It makes OS copyright a little easier to infringe, but also again (like google’s first) shows the remarkable usability of the slippy-interface and its underlying AJAX technology. This ‘blogger’ particularly likes multimap’s feature which identifies the ‘locality’ which continually updates as you move cross the map. They must have built a load of theissen polygons from the OS gazetteer to underpin this. The result works well in some places, but there’s no sign of the name on the map in others. Less good is the use of getmapping aerial imagery, which seems to have a lot of gaps, many more than it should have – people’s map wins there. And performance seems to be a struggle, you need big banks of powerful servers before you can offer a professional slippy / AJAX service – the demands of the clients are probably two orders of magnitude more than the previous technology.

Good try though – 6 out of 10.

Above Cartoon by Peter Steiner. The New Yorker, July 5, 1993 issue (Vol.69, no. 20) page 61