GeoSmart Weblog

Just another WordPress.com weblog

What Tools Do You Need to Develop a Mobile LBS Application Part 4

A key component and possibly the second highest webmap query on the Internet is for Driving Directions and this has even more relevance in a mobile scenario. Driving Directions is a key point of difference for GeoSmart in New Zealand. In many other countries, the government provides free or low cost map data of a very high quality and suitable for car navigation and other purposes. In New Zealand this isn’t the case. The LINZ maps are the official datum for cadastral property boundaries. However, their road centreline is derived by a computation of the property boundaries.

As I’ve previously mentioned, New Zealand was town planned in Edinborough in the late 1800’s and many of the roads they draughted were never formed or constructed. They are known as paper roads. These roads exist on paper and on the LINZ map data used by services such as Google Maps, but they physically don’t exist. An example is Threepwood Road in Otago. If you have a look on the hybrid mode of satellite view and map view on Google, you will see that while the road exists on the map data, it physcially isn’t there in the satellite photography. This would cause a real problem if you wanted to go for a drive on it.

When GeoSmart discovered this problem and realised that, while it didn’t matter a lot for printed maps where you still have to analyse the data and make a decision on where you drive yourself, practically speaking, if you used either car navigation or a printed set of directions and couldn’t see a map as such, paper roads could cause a lot of confusion and grief. With LINZ having the only full maps of New Zealand, we decided we had to make our own maps. To do this we drove almost every road in New Zealand and also used a lot of Orthophotography to develop a driven road centreline, eliminating all paper roads and at the same time creating an accurate road centreline.

While collecting this data, we were also able to collect information such as the intersections controls (roundabouts, traffic lights etc), turn restrictions (one way streets, no left turns), speed zones, whether the road was sealed, accuracy of street signs and much more. We were even able to establish things like the angles of corners and inclination of roads (how steep they are etc).

This enabled us to build the car navigation dataset used by all the major brands including TomTom, Navman, BMW, Ford, Siemens VDO etc. It also allowed us to create sites like AA Maps and provide the API’s used on Wises web site. Now you can go to AA Maps, plan your journey and print out turn by turn directions from anywhere in NZ to anywhere in NZ and be confident that the instructions will work.

So, from there to your mobile. The Directions Web Service will work on any device that can identify a start point and where the user wants to go. The User Interface is up to the developer  and will probably vary from phone to phone because of its controls and screen size. For example a touch screen such as that on the iPhone or Windows Mobile, would have functionality closer to a web page, whereas a phone without a touch screen would have to function differently. That is really just a design issue, not a significant barrier.

If your phone has GPS or the ability to use cell tower triangulation, it will know where it is. But it is also possible (if you know) to tell your mobile where you are and where you want to go This could be an address you want to get directions to, or it could be Points of Interest from our POI Web Service mentioned in Part 2 of this series. Once you know the start and end of your journey, you can use the Directions web service to guide people directly to your desired location.

So now you can have turn by turn directions delivered to your phone. This could be send as an SMS with text directions, it could be an MMS combining text directions with an image of the route map, or an image zoomed in to your destination, or it could be information in your mobiles web or WAP browser, with enanced functionality.

Here’s the thing. If you are at home or in the office, you can use your PC, but it is of no use to you in your car or away from the computer. You may not know where you are going to want to go until you are out on the road. An LBS application with the Directions Web Service can give you the same freedom, without the necessity of interpreting a map, or more commonly the map isn’t there when you need it. Pick up the kids, meet someone for coffee, find your way from the car park to the show. All easy to do with LBS.

Just as a footnote, a few days ago a 62 year old woman set of from Christchurch to her  home on the West Coast of the South Island. She didn’t arrive and her friends and family spent a couple of days searching for her after she crashed her car down a 5 metre embankment. She was eventually found but the story could have been very different. She may not have been found at all, or not until it was too late to save her life, or she could have been found very easily. If she had a mobile with GPS, after she had been reported missing, if the phone was within coverage, it could have been called and located using an LBS service using GeoSmart tools and her searchers could have had turn by turn directions on their mobiles, right to the spot where her car was.

I suspect this sort of application will be available within the next few years, but someone has to create it first. Tracking elderly people is something that is also a major opportunity.

April 5, 2009 Posted by | AA Maps, cartography, driving directions, geosmart, gps, lbs, location based services, maps, Mobile maps, navman, new zealand, new zealand maps, satnav, tomtom, web maps | , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , | 1 Comment

What Tools Do You Need to Develop an LBS Application Part 3

Geocoding and Reverse Geocoding are key components for many LBS Applications.

Geocoding is the process of generating a set of co-ordinates, which are subsequently used to display a location on a map. If you have a huge database of addresses, we typically do this as a batch process and have tools designed to try to compensate for poorly laid out databases, or errors such as mispelling, wrong suburb or when people like Real Estate Agents make up their own to make a location sound more attractive. A common one for example is Whangarei Surrounds. There is a place called Whangarei, but not Whangarei surrounds. Computers being fairly literal, if you try to search for a place that doesn’t exist in the database, you have to get creative.

Services like the POI Webservice V2, whichwas mentioned in the previous blog, are designed to help you with this requirement. How you do this depends on the type of application you are developing. For example:

  • If you are using an SMS service, you would have to have a very good address, if you want to get a good result. If the address doesn’t exist in our database, we can return a set of co-ordinates that are next best, for example if we don’t have the exact street address, we can return the middle of the street. One common issue in New Zealand which dates back to the days when we had lots of councils who didn’t consult with each other on street name allocation. As a consequence of this there are many duplicates. For example there are 23 different Queen Streets in Greater Auckland.
  • An autocompleter is a great way of getting to the correct address first time. You can see a nice example of this on AA Maps, where a new request is made of the POI Web Service every time a new character is entered, if the right result comes up at that point, you can click on it and then perform the action desired, such as viewing it on a map. This can function easily in a PC browser and can work fine in many mobile browsers. The main difference in a mobile would be that you reduce the number of results displayed in a list to make it user friendly on the smaller display.

For developers, there is much more detailed information in the Developer Section of our web site, including code examples. We support a wide range of results from text to javascript and html.

Reverse Geocoding is a powerful tool for mobile devices. What this does is using the co-ordinates derived from the mobile phone, we can display the users current location on a map. What we can then do is provide information about Points of Interest close to the user.

The first thing we can offer is the nearest street address. This can be used in various solutions such as

  • Buddy Finder
  • Locating children or elderly people, to ensure they are where they are supposed to be. This can include things like geo-fencing (which will be explained in a future blog).  The concept for children or elderly people might be to make sure they are at school, or perhaps close to the home or retirement village. It is very common for elderly people with Alzheimers or other conditions to wander off and then lose track of where they are or how to get back. Reverse Geocoding could enable authorised people to find out where they are if they have gone missing. Geo-fencing allows you to create a ring or polygon around the area they should be at, for example the gardens and surrounds of a rest home, but set of an alarm within a system if people leave that area, or go within a predefined distance of that area.
  • Locating people for health purposes. For example a system in Europe was designed to locate people such as diabetics who are away from their home and don’t have their insulin with them. Reverse geocoding could locate exactly where they are, while a proximity tool could identify the nearest Pharmacy which could prepare are dose and put it on a taxi to the patient’s location, even if they are disoriented and not sure where they are themselves.

This leads on to another benefit of reverse geocding in mobile applications. One of the most common services being developed for mobile applications is the ability to find Points of Interest nearby the location of the person’s mobile, without them having to be able to identify their location. This would then utilise either a proprietary database, or the GeoSmart subscription POI database which was mentioned in our previous blog. We have an extensive database covering most locations you might want to find when you are out and about. It could be (follow the links for examples on AA Maps web site) a motelBP petrol station, a public toilet, a National Bank ATM, a pharmacy, cafe or pretty much anything. This makes it really for people to find anything they need within proximity of their location, without having to kow where they are.

Proximity Based Marketing will be a huge growth area for LBS which is enabled by these tools as is Location Based Social Networking.

Of course if you now have the co-ordinates of where you are and the co-ordinates of the location you want to go to, you can now offer turn by turn directions to that location n the mobile. This will be the topic of our next blog, so if you are interested in this subject, please bookmark this blog, or add it to your RSS aggregator such as iGoogle.

Geocoding and reverse geocoding a critical tools for mobile LBS applications.

April 2, 2009 Posted by | AA Maps, driving directions, geosmart, GIS, gps, lbs, location based services, maps, Mobile maps, new zealand, proximity based marketing, satnav, social networking, web maps | , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , | 2 Comments