Google have acquired a new JavaScript engine (V8) written from the ground up to work more efficiently with websites that have large amounts of JavaScript rather than the little snippets of JavaScript which was typical of websites developed when JavaScript was first integrated into Netscape Navigator in the mid 1990s.

Typically JavaScript engines use a dictionary-like data structure as storage for object properties – each property access requires a dynamic lookup to resolve the property’s location in memory. V8 works differently…the first time V8 encounters an object it interprets how the object would be represented as a class, creating a hidden class, which means the next time the object is encountered, its properties can be accessed from memory without the time consuming dynamic look up.

Google give a far more comprehensive introduction to this approach in their documentation of V8, conveniently they use the example of an object common to all GIS developers…a Point.

So What?

The novel approach taken by the V8 JavaScript engine, presents a new opportunity for GIS web developers to work with Points, Lines and Polygons on the web client instead of the web server as is typical of a web based GIS. Using JavaScript in the web browser removes the need for lengthy round trips to the Server, which will make for faster web mapping applications.

Here and now, this will allow web mapping API developers to work with more markers, the typical 100 marker limit of Google Maps applications (and similar web mapping API’s) – is no more; Mike Williams and his team have reported working with as many as 2000 markers when using Google Maps within Chrome.

Chrome isn’t the only web browser to recognize the importance of working with JavaScript heavy web sites, for example, much work is being done on a new JavaScript engine for Firefox. Perhaps in the future, as this approach gains support, spatial analysis functionality can move from the server to the client, which would make for a more engaging web mapping experience?

If anyone is looking for a dissertation project, or has time of their hands, it would be interesting to see the outcome of taking some topological operators (e.g. Java Topology Suite), Google Web Toolkit (GWT) and GWT for Google Maps, all served up with Google Chrome?

It turns out, a couple of years back Nokia embarked on a project to port the Apache web server to the symbian operating system that underpins their Series60 device platform. The project was subsequently handed over to the open source community and you can get involved here, project raccoon. Interestingly, Nokia have recently wrapped the web server as user friendly software with a supporting website: www.mymobilesite.net.

I installed the application on my N95 and as you might expect it provides complete access to the contents of my mobile phone via the web. I can fire up the web browser on my desktop PC and browse to a web page, and then click a button on the web page to take a photo with the camera on my phone, wherever my phone might be. I can then use my desktop web browser to browse the photos I have taken, or any other information I have on my phone e.g. contact details or calendar events.

This struck me as a unique piece of software, I tried to think of other software that functioned in a similar manner. After roaming the web for some ideas I found an article from Tim O’Reilly that suggested similar behaviour could be observed with Apple iTunes, he’s coined a term to describe such software as…‘software above the level of a single device’.

Installing the mobile web server software on your phone, allows you to use the software on any number of devices…your phone; a desktop client with web browser; a games console; or any other internet enabled device, even someone else’s mobile phone? Software above the level of a single device – just as Tim O’Reilly describes when he observers that you can control your iPod from an iMac.

From a geospatial perspective, couple the GPS enabled N95 mobile phone, with the mobile web server, and we have a tracking service that can be consumed by any internet enabled device, powerful stuff. Perhaps worthy of more consideration, I look across the GI industry, GIS software vendors, the open source community, and other corners, but I don’t see ‘GIS software above the level of a single device’ as an overriding design architecture?

There is a bigger question here…what happens when 3 billion mobile phones run as personal web servers?

I think it’s a great opportunity for students, surely better than spending many summer months obsessing on an esoteric thesis that will never see the light of day – perhaps that was just my experience? Christopher Schmidt and others have offered their support for students wishing to further develop OpenLayers, it would be great to see some of the stuff on the list tackled.

The CAPTCHA was created by Luis von Ahn, in an attempt to fight Spam…if the CAPTCHA is completed successfully you are assumed to be human and the web form is submitted, if the CAPTCHA is failed you are assumed to be a computer and web form submission is prevented. The CAPTCHA is a classic example of a Turing Test, as proposed by the eponymous researcher in his 1950 paper ‘Computing Machinery and Intelligence’ – indeed the name CAPTCHA coined by Luis von Ahn is an acronym for a “Completely Automated Public Turing test to tell Computers and Humans Apart”.

The Internet Archive is attempting to automatically digitize old books using optical text recognition software, they are largely successful but the text recognition software struggles with recognizing ye olde English, meaning that roughly 8% of words are digitized incorrectly or not at all. reCAPTCHA addresses this problem by asking a user to interpret a picture of two words (instead of just one), the first word is a known word and the second word an unknown word. If you correctly interpret the first known word, it is assumed you have also correctly interpreted the second word that wasn’t recognized by the text recognition software. So when you fill in a reCAPTCHA, not only are you proving that you are human, but you are also helping to digitize old books! For me, application of technology in this way is poetry.

Obviously Luis von Ahn has applied this technique to digitizing old books, but it had me thinking of the potential to apply such an approach to digitizing maps…is there scope for a geoCAPTCHA?

The above cartoon is the copyrighted work of David Farley

With this advert for a ‘Senior GIS Engineer’ from Realtime Worlds, the computer game company behind GTA, Lemmings and Crackdown, it looks like the computer games industry is keen to leverage the benefits of GIS…

Responsibilities

Development of a software framework and tools to process, convert and integrate multiple sources of GIS data.

Investigation and assessment of new GIS data sets.

Supervision of engineers and proactive role in software architecture.

Qualifications Required

Good BSc or equivalent in a relevant subject.

Experience Required

3 years’ professional Software Engineering in a team environment

Knowledge/Skills Required

C#, C++ or Java

PC / Windows development

Ability to communicate ideas well and assist junior programmers

Experience working with large data sets.

Experience with standard GIS data formats and tools (vector, raster and terrain data)

Knowledge/Skills in the following areas a plus

Scripting (such as shell or Perl)

Databases (SQL)

If the job interests you (and you want to live in Dundee), check out their website for further details.

Having vague recollections of working with Java whilst undertaking my undergrad dissertation at Lancaster way back when, I plumbed for Java and promptly downloaded the Eclipse IDE. Next up, I installed Carbide.j, a suite of mobile development tools from Nokia. It was at this point I encountered my first frustration; it turns out the Carbide tools from Nokia don’t support the latest version of Eclipse, a school boy error of failing to read the doc. A quick uninstall, download, and install later, I’m back on track with an older version of Eclipse (3.1.2).

Nokia have provided a whole host of up-to-date documentation for building LBS applications for the series60 platform, so I downloaded their TouristRoute Java Midlet example and their location API developers guide. The location API is pretty concise, with a handful of important classes:


LocationProvider: represents the source of the location information (in this case the integrated GPS)

LocationListener: receives events associated with a particular LocationProvider.

Coordinates: represents coordinates as latitude-longitude altitude values.

Location: represents the standard set of location information (time-stamped coordinates, speed, accuracy, course, etc.)

Landmark: represents a known location with a name.

LandmarkStore: has some methods for persistent landmark store management (store, delete, and retrieve landmarks).


The sample built fine, generating a Java Archive (JAR) file and Java Application Descriptor (JAD) file. The JAR file is a package of the classes and resources, the JAD file a description of the Midlet. Right clicking on the JAR file (the midlet executable), the Eclipse context menu gives you two deployment options:


1) Deploy by Bluetooth
2) Deploy to Web Server


Unfortunately my laptop doesn’t have Bluetooth, so I went with option two and uploaded the files to my server (they can be downloaded here). I uploaded both files, the JAR and the JAD, I’m not sure if both are required or not? I added corresponding mime types to the .htaccess file on the server (this instructs the server how to handle requests for jar and jad files) and browsed to the jar file with my mobile phone browser. A couple of keypad clicks later, the application had been downloaded and installed on my phone.

I have had the phone for a couple of months now and am very impressed. Nice design, great camera, and a half decent GPS, but it’s the open development platform that sets this phone apart from the crowd, allowing everybody and anybody to develop a whole host of useful (and not so useful) applications. So far I’ve already acquired SportsTracker, which allows me to save my mountain bike routes as KML, some handy software that uploads my photos to my Flickr account, and the ubiquitous Google Maps which syncs nicely with the GPS.

Obviously, it’s a great plug for his book, but David Platt makes a good point in the video clip and something we continue to remain aware of here at ESRI. On this front I think ESRI make a fair effort, and a lot of time and energy is invested to ensure it’s the ‘end user’ experience that drives software development. For example, all our core software engineers are loosely coupled to product engineers (or product specialists), and it’s the product engineers that drive software development from an ‘end user’ perspective – at least that’s the theory; sometimes we get it right, sometimes there is room for improvement.

After watching the clip I surfed to Dave’s website whysoftwaresucks.com, where he has posted a sample chapter, I think he makes a valid remark when he states:

“The designers of the earliest computer programs didn’t care about making their products easy to use. Solving the computing problem at hand, for example, dealing with a printer to make the words come out properly on paper, was so difficult that no one had time or money left over for making a user’s life easier. A computer’s thinking time was enormously expensive, much more so than the user’s time. Forcing the human user to memorize complicated commands, instead of using computer power to provide a menu listing them, made economic sense. The relative costs are now reversed, of course, but almost everyone in the industry older than about 30 grew up in that type of environment. It can’t help but shape our thinking today, no matter how hard we try to leave it behind. Think of your older relatives who grew up in the Great Depression of the 1930’s, who even today can’t bear to throw away a sock with only one hole in it.”

Do GIS developers drive shift sticks?