Can you find who you’re looking for, or are you stumbling around blindly? Is geolocation the answer?

You’re pretty pleased with yourself. You over-committed to your boss on delivering a web-based application for your salespeople. Thinking back on that commitment, you had four functional requirements:

• Real-time access to IBM i data and local storage when no mobile connectivity is available
• Ability to take pictures, store them on the device, and upload them
• Ability to retrieve and store geolocation information
• Ability to record audio for taking “audio notes”

Smart programmer that you are, you took the “spinach before the ice cream” approach and tackled the two toughest first: Data access and storage and taking pictures with the device's camera and storing those. So you move on to easier tasks, and the next one is so simple you think you could do it in your sleep: retrieve and store geolocation information.

The browser tends to be a “frenemy”: It makes some things simple, while at the same time, some niggling differences can make your life miserable because of dealing with browser incompatibilities. When it comes to geolocation, though, there has been broad, consistent support for getting your location coordinates. It all starts with the navigator.geolocation object.

Let’s say that you need to get the location of the salesperson. If they happen to be in an office on a PC, the navigator.geolocation object will most likely use the external IP address of the gateway/firewall to figure out the best approximation of location. On mobile devices, there can be many sources of location information: Gateway IP (if on wireless network), cell tower triangulation, or native the GPS API could be used. In any case, “your mileage vary” as they say. You might be able to get accuracy down to a few meters, or it could be a few miles. The “few miles” accuracy usually comes into play when you’re on a wired/wireless network. Most mobile devices, when using GPS, can narrow it down to a few meters.

Some quick code to show how to obtain your location coordinates:

// First check to see that your browser supports it

var positionCoords = “”;

if (navigator && navigator.geolocation) { // looks good, do something

navigator.geolocation.getCurrentPosition(showThePosition, handleAnError);

// two callbacks passed

}

function showThePosition(position) {

   positionCoords = "Latitude: " + position.coords.latitude +

   "<br>Longitude: " + position.coords.longitude;

}

Of course if we want to store that data, we can just push it into our local storage as an object, like so:

{

      "positionInfo": {

            "latitude": "position.coords.latitude",

            "longitude": "position.coords.longitude"

      }

}

Cool! Coordinates are easy to get, but what use would they be? Well, I can think of a few. Salespeople are on the road a lot, so making it easy to locate the nearest customer would be a plus. That would take just a bit more work, though. In order to find customers, you'd need to have their coordinates in a database (geocoding) so that you can determine how far they are from your current location (geolocation). Geolocation is basically free in that your browser can tell you where you are at any time geolocation services are available. Geocoding, on the other hand, is not free. Well, it's almost free, but there are caveats. Most geocoding is done using the Google Maps API. It is a well-known, stable, and easy-to-use API, but it has limits on the “free” use: 2,500 free requests per day, 10 requests per second. Anything beyond that and either you’ll get an error or you'll need to pay $0.50 per 1,000 requests. The good news here is that most of your customers aren't changing locations frequently, so using the API to geocode and then save the coordinates to a DB is your best strategy. Don't geocode the customer's address every time you need to locate the customer. Geocode the addresses ahead of time and store the coordinates. If you have 10,000 customers, schedule your geocoding and storing to the database in blocks of 2,500 per day.

Geocoding tends to be done for fixed, relatively permanent addresses like customer files. Geolocation, provided by the browser, tends to be used for information captured on site. Applications for geolocation services would include these: capturing location coordinates for onsite reports and pictures, determining distances from your current location to a known location, surveying over a large distance where pinpoint accuracy isn't needed, or perhaps confirming customer site visits by tracking location over time.

Your app says “Marco!” and the response is “Polo!” That’s three requirements down and one to go.

Peter Helgren is programmer/team lead at Bible Study Fellowship International. Pete is an experienced programmer in the ILE RPG, PHP, Java, Ruby/Rails, C++, and C# languages with more than 25 years of system 3X/AS400/iSeries/IBM i experience. He holds certifications as a GIAC certified Secure Software Programmer-Java and as an MCSE. He is currently executive vice president on the COMMON Board of Directors and is active on several COMMON committees. His passion has always been in system integration, and he focuses on open-source applications and integration activities on IBM i. Pete is a speaker/trainer in RPG modernization, open-source integration, mobile application development, Java programming, and PHP and actively blogs at petesworkshop.com.

---

MC Press books written by Peter Helgren available now on the MC Press Bookstore.

		Open Source Starter Guide for IBM i Developers Check out this practical introduction to open-source development options, including XMLSERVICE, Ruby/Rails, PHP, Python, Node.js, and Apache Tomcat. List Price $59.95 Now On Sale