A little bit of this, a little bit of that, but probably mainly javascript

Ever since I could connect wires, I liked electronics giving feedback about changes in the physical world. During my highschool years this was demostrated by my little door switches and LED indicators setup, so I would get an early warning when my parents came home. Many years later I was completely blown away when a mobile device showed where I was and with great precision. My enthusiasm might have faded somewhat over the years, but location was still the first thing I started playing with recently, during the PhoneGap workshop at Mobilism.

To get all the info possible about my location, my demo app utilised both the geolocation and compass APIs and worked like a charm. Looking at the specs, in particular the coordinates interface, something started to bug me. It didn’t make sense! According to the w3c spec ( which PhoneGap’s API is based on ):

interface Coordinates {
    readonly attribute double latitude;
    readonly attribute double longitude;
    readonly attribute double? altitude;
    readonly attribute double accuracy;
    readonly attribute double? altitudeAccuracy;
    readonly attribute double? heading;
    readonly attribute double? speed;
  };

I would like to point out that heading here denotes the direction of travel and must return NaN when speed is zero. The compass on the other hand simply “Obtains the direction that the device is pointing”, returning a single value for heading. Now there is w3c spec for compass, but I think these APIs need to be sorted out nonetheless.

First of all, I think the position and movement describing APIs should either be seperated or united in a much more logical manner. Lo·ca·tion by definition, refers to a particular place or position, so should contain attributes needed to describe just that, namely latitude, longitude, altitude and heading ( will skip the accuracy attributes ). Almost the same, right? Well, 75% true. The first 3 attributes are the same as in today’s spec, but the heading attribute in geolocation should refer to what is returned from the compass API, the direction the device is pointing. After all I can easily stand in one place, turn in any direction and my location should reflect this.

Ve·loc·i·ty, by definition, is the speed of something in a given direction. This is what the speed and heading attributes of the current geolocation API return, but these should NOT be inside geolocation, since they are not describing a particular place or position. These attributes should be in a seperate, let’s say, geovelocity API or simply velocity API.

If you are all confused now, here’s an example to imagine: You are sitting in a car travelling west while staring out the window facing north, taking pictures with your device. The location of any photo taken should describe its geographic coordinates, plus that your lense was looking towards the north. On the other hand a navigation app should continue to update the map showing the direction the car is moving in, so in this case, west. Did that help?

So to sum it all up, I suggest 2 APIs:

geolocation {
    latitude;
    longitude;
    altitude;
    heading;
}

velocity {
    speed;
    heading;
}

I could imagine another solution, for the sake of backwards compatibility, where all attributes remain inside the geolocation, but this would require a straight forward, clear word as attribute name for the compass’ direction. One that doesn’t refer to both the way something is pointing and moving. I prefer the previous.

What do you think?