Monthly Archives: April 2013

Positioning in Geospatial Systems

For geospatial applications, to understand where you are, and what is around you, there is a requirement to have a representation of your location and the location (or relative position) of other nearby objects. In this post we will look at the format in which your position is received from a GPS or other location sensor, how it can be converted to a format consistent with other data sources and how that position can be used in a 3D environment (which could subsequently be used for visualisation, for example).

This blog is written to give an overview of the conversion process of Latitude and Longitude positions to Cartesian coordinates that can be used in a 3D gaming engine. It is not going to go into the maths of how the conversion from geodetic to planar systems works or the related aspects of accuracy and precision. A future blog will address these in general, with specific references to the situation in the UK.

Location Sensor on the Device

Getting the location on a mobile device is a bit more than just turning on the GPS. Location information requested from the location sensor can be derived from the mobile cell your device is currently in, nearby Wi-Fi networks or, satellite positioning systems (such as GPS or GLONASS). There are pros (accuracy, speed of obtaining a fix etc) and cons (battery life, accuracy) of each type. I will assume we are getting a satellite fix for the rest of this post and commonly refer to that as GPS.

GPS gives positions in the World Geodetic System (WGS84) as this provides a unique location (co-ordinate) for any point on the planet. Valid GPS values are between -180 to +180 longitude and -90 to +90 latitude. Let’s have a look at an example, our office is at 3 Wellgreen Lane, Stirling in Scotland and when I request a value from a GPS sensor, I get:

Latitude: 56.1154620496249
Longitude: -3.93572384820349
Altitude: 80
Accuracy: 32

This has represented our position in three parts: latitude, longitude and altitude with an associated horizontal accuracy.

Geodetic and Projected Cartesian Coordinates

The maths required to work with geodetic coordinates such as WGS84 is difficult because you are not working on a plane. Specifically there are issues relating to convergence as you get nearer to the poles. At the equator a box 1 degree latitude by 1 degree of longitude is essentially square. As you get nearer to the poles, convergence of the longitude lines occurs and your “box” changes shape. More details can be found here.

For mapping, measurement and visualisation systems, it makes sense to convert geodetic coordinates to a planar projection. In the UK we have a well defined coordinate system (projection) defined by the Ordnance Survey and commonly referred to as the National Grid or OSGB. This is also handy as the points of interest feeds and spatial data we use in the UK are mostly published using positions on OSGB.

It is fairly easy to find examples of conversion from WSG84 coordinates to OSGB coordinates, Moveable Type have a handy online converter to show the process. When we put in the values taken from the GPS sensor at our office in, it converts our position to OSGB:

National Grid conversion

An OSGB representation of the position of our office could be (given the caveats in the introduction above):

Eastings: 279736
Northings:693100
Altitude:80
Accuracy:32

Planar Cartesian projected (eg OSGB) positions are easy to understand because a local, relative frame of reference represents the number of meters from an origin. The OSGB origin is somewhere southwest of Land’s End in the Atlantic Ocean. So our position says we are 279736m (280km) East and 693100 (693km) North of this origin position.

More information can be found from the OS interactive Guide and OS A4 Guide

3D World Coordinates in a 3D Gaming Engine

CoordinateAxesNSEW.WhiteBackgroundThe 3D Gaming engine represents positions using a 3 dimensional Cartesian system. Positions are represented by given an (X,Y,Z) coordinate.

We use Vector3 structure to represent positions within our 3D system. This position is taken from the OSGB location where X is the Eastings, Y is Altitude, Z is Northings. The location of our office would be represented as:

X:279736
Y:80
Z: 693100

This allows us to make use of the same origin as OSGB and makes the logic simpler to understand.

Summary: WSG to Vector3

We’ve seen a worked example of the position of our office in Stirling in the three different coordinate systems we use. Below is the summary.

GeoCoordinates Example

Mobile Application Development

Our History
Linknode are an app development company. We have have a portfolio of apps available across different platforms and their stores. We focus on cross platform sensor driven applications that fit with in our Mobile Geography domain. This post is going to be a tour around our app portfolio and what we learnt along the way.

How it started: EmergencySMS

LinkemergencySMSnode’s early apps were all for the Windows Phone market. It all started with the launch of Emergency SMS in June 2011 (the company was 2 months old at the time). This application takes the devices location, looks up the address and creates an SMS message that can be sent to the UK’s National Emergency SMS.

EmergencySMS is still available in the Windows Phone marketplace, and is still used by customers: it gets 10-20 downloads a day. I don’t consider it a masterpiece of design or implementation but it is a good place to start.

  • Start small, your apps may last longer than you think.

MegaTile – free version and premium features

MegaTileAnother consumer app (and most successful in terms of revenue generated) is a called MegaTile and allows the user to customise their home screen on Windows Phone 7 and 7.5. The user can choose an image to make a MegaTile from and set an action (launch phone dialler  send SMS, open web page etc.) for each tile.

  • Have a free version, it make users download it and gets them to convert to the full version. 7% of our users purchased after running a trial.
  • Test the upgrade process of your app on each release. We didn’t and caused ourselves a lot of negative comments from users who were unable to upgrade between v1.2 and v1.3.

Album Flow – Use a Design Pattern

AlbumFlowWe had an idea to bring the iOS style coverflow to Window Phone, this resulted in the Album Flow application. The initial version of this app was ready in 3 days. We are just polishing our 9th release and have over 100,000 users. Album Flow was featured by Appvertise (Nokia and Microsoft) and won a CreativeBloq App Generator Top Ten App.

  • Use a design pattern to make your code consistent and understandable. We use the MVVM pattern and the MVVMLite library to support it.
  • Respond to user demand and comments to get better reviews and more satisfied users.

Starting out in Augmented Reality

Where On Earth, and its cut down version – Heads Up Compass, are two apps that started to define the GIality concept and are the first examples of the use of GIality on a mobile.

HeadsUpCompassHeads Up Compass takes the data from the devices motion sensor, uses it to work out which direction you are looking and superimposes that on the camera feed. Calibrating the compass and getting accuracy from the device sensors is hard. Use the Combined Motion API on Windows Phone or equivalent on Android or iOS for better results than just a single sensor.

Where On Earth goes a step further and looks up features around you to help identify features (hill tops and towns currently) that you can see in the camera view. Where On Earth was customised for a team entering the Oxfam Trail Trekker to provide them with a heads up display of check point locations and distances.

WhereOnEarth

  • Review your maths text book: Quaternions are good when working in Augmented Reality situations, but complicated to get your head round.
  • Mobile apps should work when out of mobile signal. Design to manage offline access and syncing data. These a whole other blog post in this topic.

Windows Phone Development Summary

All of the apps covered above are only for Windows Phone. I love the process of developing for Windows Phone.

  • The tools are excellent – I can use Visual Studio (which I have plenty of experience with and is set up exactly the way I want it).
  • I can switch to Expression Blend if I want to do some more complicated user interaction.
  • I can use C# a popular language that many developers who have worked in enterprise understand.
  • Having come from a web background, I would much rather do layouts in XAML than in HTML / CSS.

My biggest complaints so far have been to do with the store and submission process (not being able to cancel an app being certified) and understanding some of the SDK design decisions taken to do with the back stack and Navigation.

Evolving Beyond Windows Phone

In mid 2012 we decided that Windows Phone was not a big enough market for some of our mobile geography plans (Although it may be getting there according to the latest stats from Kantar). Specifically we wanted to expand into using running our GIality solutions on a tablet. Whilst Windows 8 was coming (it launched October 2012), we wanted to start running GIality apps on tablets right away. We chose Android as our first tablet platform: specifically the Nexus 7 and when it was released the Nexus 10 .

VentusAR: Support for Android

Ventus_logoOur first cross platform app was VentusAR. This is a Business to Business application (so it’s not available in the Play Store) to allow you to visualise what a wind farm would look like if it was built as planned. There are many different parts to VentusAR that all need to work together and need to work across multiple platforms. The main application logic needs to be complied by the Windows Phone and Mono for Android compilers (we’ve since added Mono-touch for iOS and Windows RT compilers too).

Coming from a Windows Phone background, Android development (even using Mono for Android and Xamarin tools) feels a bit of a disjointed mess. I guess it comes of saying anyone can customize the OS to run on any hardware (the Android approach) rather the OS will only run on our hardware (Apple) or the OS will only run on hardware that meets strict guidelines (Microsoft’s approach).

  • Think about making the app cross platform-able early on. Its easier to start that way than to try to change an existing app to be cross platform.
  • The android emulator is too slow to use for real development, buy a proper device to develop on – it’s much quicker.
  • Android Resource qualifiers (screen resolution, pixel density language etc.  make designing and testing Android UI’s very hard. The Xamarin Designer helps a lot.
  • Run an automated build server as changes in the android app can have unintented affects in the other builds.

3DTry.it: Available for Windows Phone, Android and iPad

3DTryit_logo_websiteOur first public cross platform GIality app to launch is 3DTry.it (available for Android, iPad and Windows Phone). This is an app that allows the user to view published 3D models on their tablets on top of the the camera view. The models rotate as though they are in the real world. Download it from the app store if you want to see it in action.

  • The motion sensor frame of reference is different on different devices (the nexus 10 is 90°different from the Nexus 7).
  • Xamarin tools allows iOS apps to be developed on a Windows PC which speeds up development for windows users.

Summary

Having tried developing apps for all three platforms, I enjoy developing for Windows Phone the most (maybe that’s because it was the first one I started developing for). Android is frustrating due to the number of different devices, screen resolutions and version available. iOS development in c# is made easy using Xamarin tools, which have done the job for us so far.

SMART: Scotland Grant

SMART: Scotland Grant
Linknode are delighted to have been awarded a SMART: Scotland feasibility study grant to support our development of 3D and mobile systems for GIality (geospatial augmented reality).

SMART: Scotland provides discretionary grants to Small to Medium Enterprises (SMEs) based in Scotland. Categories for grants include technical feasibility studies and research and development (R&D) projects with a commercial endpoint.

SMART-Scotland Programme

Linknode’s grant is a “Feasibility Study” covering early stage proof of concept R&D in order to enable informed decision making on the technical risk assessment for a new product or process. Our project was awarded in February 2013, contains eight primary objectives and will run for much of the year.

The first research element undertaken in support of our VentusAR vision is the ability to integrate the location and orientation sensors on a mobile device with geospatial services that deliver terrain models and 3D objects in order to create an on-site visual impact support tool. Using mobile gaming engines to make the solution work in real-time with appropriate levels of detail and lighting is the main challenge here, along with our goal of ensuring we deliver cross-platform mobile development.

Linknode thank Scottish Enterprise for the management of the SMART: Scotland programme.