The next generation of location-based services uses live location to make assignments, track orders, track miles, personalize experiences, and power great product experiences. A fleeting glimpse by product managers and developers might lead to a false view that maps platforms are sufficient to build these features. This post covers what maps do and don’t.

Say you want to build an in-app tracking view of an order. It needs to be a smooth experience (think animated icons) with accurate location (route polylines maybe) live ETA (that updates every minute) user/order information (a drawer to reference) and trip status (why is it stuck there). To build this what can developers count on maps for and not? Read on for the answers.

Maps APIs: What they are good for

Let’s first talk about what maps do well. Of the world of things that maps do this is a list of capabilities that are most relevant for developers building live location features.

  1. Routes with miles and ETAs: Maps tell you the route between two points with distances and times factoring mode of transport and current traffic conditions. For instance knowing expected routes helps assign a job to a professional based on customer location. Maps do a great job of getting this information through APIs.
  2. Visuals: Maps are the backdrop for showing available cars on a map for instance or showing a person moving towards a location or viewing heatmaps of supply and demand or reviewing the location and activity timeline of a user. Maps SDKs help render visuals within the product experience – on web or smartphone – full with pan zoom place markers pins and icons.
  3. Places: Maps help locate the address where the user is going. Reverse geocodes help understand where the user has been. Places data is one of the more valuable (and expensive!) building blocks in the world of maps. This stack is getting deeper as cars start driving themselves and drones start flying themselves.
  4. Snap-to-road: Custom GPS chips vehicle tracking systems and smartphones generate location streams but they are noisy. Plotting them directly on a map is a fool’s errand. Maps help snap these points to road through APIs.

Google Maps is the API of choice with a generous free tier for starters and then a steep price increase sometimes in steps of tens of thousands of dollars depending on the APIs you use. Mapbox is an awesome alternative with richer visual experiences and a whiter box to play with. For the brave of heart the services listed above can be built and hosted in-house using OpenStreetMap or other data sets available locally. In full disclosure HyperTrack uses all three for different purposes. We love each of them for what we use them for.

Maps APIs: What they don’t do

Now let’s talk about what maps don’t do well or don’t do at all. The first step to building out live location features is to generate location data. Turns out you go to maps with a set of locations but you are on your own to generate them in the first place.

  1. Generate location data: Other than the top maps companies in China those in the rest of the world do not provide SDKs to generate location data. Location data generation needs to be a fine balance between accuracy and battery drain. It needs to factor network location and device outages in the big bad world leading to data errors. It is a complex problem and maps companies consider this the domain of the smartphone OS real-time communication libraries that connect devices to the cloud steroid-like SDKs that form a layer between the device and the server and other such alternatives.
  2. Generate activity data: The Operating Systems are getting smarter about powering live location in battery efficient ways. The world changed nearly a decade ago as mobile chipsets built an engine that automatically selected between locations from cell tower triangulation Wifi IPs GPS module and more so the OS could pass that along to apps for location-based services. The world changed again a few years ago when the chipsets and OS used machine learning to create smart sensor engines that used accelerometer gyroscope signal strength and other sensor data on the device to power services like steps and activity (walk run stationery automotive etc.). Activity data provides necessary context to location data. The device and OS will do more in the coming years to service location-based services in more powerful ways. However managing and serving this data is beyond the domain of the OS and well beyond the domain of maps.
  3. Power location accuracy: Using activity data to provide context to location data has become an important way to power location accuracy. You are probably wasting your time if you find yourself dealing with a string of latlongs in log files to power live location features. Even with activity data the ability to power accurate locations under varying real world conditions is hard and to do so in real-time is harder. Relying entirely on maps APIs to snap locations to road or places is susceptible to the garbage-in-garbage-out syndrome.
  4. Mapping location data and maps with business workflows: Generating accurate location and activity data is complicated. Making maps primitives come together for live location features is complicated. How do these two complicated pieces come together in the cloud so you can plug them with your business in useful easy flexible and extensible ways? Let’s take a slightly closer look.

Mapping location data and maps with business workflows

Tracking miles for the day is not as useful as tracking miles of a sales person for customer visits or tracking miles of a cab ride to bill the customer for it. Tracking real-time location of a user is not as useful as tracking the order or visit or pickup or drop-off, especially if running late or dealing with the unexpected. Tracking current location of a number of service professionals in an area is not as useful as finding the nearest available one who is eligible to service the job request. Tracking live location of friend is not as useful as knowing how far they are from getting to where you are or a mutually agreed location for the meet up. Context is everything. Location data and maps need to work for the business rather than the other way around. Business context must be an essential part of the architecture of your location stack and not an after-thought.

This way data is generated in the context of business actions (e.g. visits rides orders pickups drop-offs jobs meet-ups) and maps are used in the context of the same actions. Data is then queried analyzed and visualized in the context of business actions. It is critical to connect up location data and maps with business workflows as part of the software design. This makes the data feature-ready for your application and enables developers to quickly build simple and useful features for your business.

Besides data it gets important to manage the costs in terms of the business actions as well. Both device-to-cloud location libraries and maps libraries charge per API call or technology interaction. They offer per device pricing at best. The responsibility to comprehend and manage the cost per business action is left to the developer. This may lead to developers cutting corners in using the technologies right or use it in ways that comes back to bite them (or someone else in the organization) in unpredictable ways in the future.

HyperTrack has built infrastructure on three layers – device cloud and maps. The device stack sits on top of the goodness that the OS powers and is sure to stay current with the latest and greatest. The maps stack sits on top of the goodness that maps power and is sure to stay current as well. It all comes together packaged as actions in the cloud. Actions map cleanly with business workflows. Each use case – order tracking live location sharing mileage tracking location-based assignments user profiling – is a few lines of code using actions. That way individual developers can independently build features with all the control and none of the hassle.

To keep things simple and transparent the HyperTrack pricing maps cleanly with business actions so customers retain control of cost regardless of number of features amount of data number of API calls with device or maps and length of tracking. Go ahead and give it a spin.