Developing web mapping applications used to require a large amount of expertise, a massive amount of data and a large server infrastructure. Nowadays, with Cloud Platforms and APIs like the Google Maps API, any developer can easily create a mashup of various tools and integrate location-based services with limited expertise in geospatial.
While on the surface selecting and developing applications using these services appears very simple, Korem often ends up helping customers who have neglected several aspects of the integration process. These mistakes can have impacts ranging from higher fees, longer timelines, and even the need for a partial or complete reimplementation.
Based on our experience, here are the 5 most commonly overlooked aspects of developing with location-based services:
The hidden face of basic capabilities
However, when you start digging deeper you notice important differences in the more advanced capabilities and service limitations. That’s why it’s important to identify the key requirements that matter the most to you.
For instance, a company developing a fleet management solution may put more emphasis on retrieving weight restriction attributes for truck routing and get the maximum query-per-second (QPS) in order to track their fleet properly.
On the other hand, a retail company developing an online ordering system or public-facing website may put more emphasis on flexible and user-friendly autocomplete address features, or the street view integration. Other companies may be more interested in batch geocoding processes that are done automatically behind the scenes and require more conservative matching with full-matching traceability.
Each solution has its strengths and weaknesses and it all comes down to what is best suited for your business goals.
The Data under the hood
The quality of the underlying data is as important as the exposed capabilities. Each vendor will provide a different level of data reliability, richness of attributes, coverage, etc. It’s often difficult to understand these differences and measure the impact they can have on your business. In the Location Services world, data quality refers to all validation processes applied to the data, while accuracy can be defined as the degree or closeness to which the information on a map matches the values in the real world (GIS Lounge). For example, vendors don’t use the same acquisition methods to provide imagery. Aerial imagery is updated less frequently and provides higher resolution while satellite imagery has a higher refresh rate with a lower resolution.
Another consideration is the coverage. Depending on the solution, the data quality from one country to another can vary greatly. This can be explained by the focus/mission of the provider. Some vendors will perform well in rural areas while others will be better in urban areas. Some providers will focus on consumer mapping and others on business mapping or in the automotive industry.
This is also linked to the way the data is acquired: from crowdsourcing, government or field data acquisition. Beyond coverage, each provider also has automated and/or manual data validation processes which ensure that the data is accurate.
THE TERMS AND CONDITIONS: THE DEVELOPERS BLIND SPOT
One of the biggest blind spots that developers are facing are the terms and conditions (T&C) of their APIs and geolocation services. Companies often assume that if the API allows implementing something, it should be legal, right? Less than 20% of developers we spoke to have read the T&Cs before they begin coding!
One quick example: did you know you can’t store/cache data from the Google Maps Platform (GMP) for more than 30 days? If you are under a GMP subscription, that means you need to geocode your client’s list every 30 days to be compliant with the terms.
Here’s another one: are you creating new output based on the API requests? Depending on the provider, some will allow to use their data to create what they called “derived content” while others prevent it.
The business impact of not considering the T&Cs at the beginning of the application development phase can be translated into a considerable loss of time and effort. This platform should be discarded right off the bat if it doesn’t fit your use case.
Another challenge resides in estimating and comparing prices. Each solution has different pricing models that range from very simple to complex. Some are based on the number of users while others are based on the number of transactions and credits with volume discounts. In many cases, the use cases and type of deployment may impact the pricing.
For these reasons, some vendors will ask a lot of questions about your use case, because your answers will eventually drive the pricing accordingly. This explains why it is often very difficult to compare solutions.
Are you building a fleet management and logistics app or a store locator? Those two different use cases require roughly the same capabilities, but not the same volume of requests and are not priced the same between vendors. The OEM vs. ASP models can also affect the way vendors will price or license your use case. It is also difficult to estimate usage before that application is live if you don’t have any benchmarks.
The business impact of not considering the T&Cs at the beginning of the application development phase can be translated into a considerable loss of time and effort.
The pricing structure
As previously mentioned before, the pricing structures are a real headache when it comes to comparing them.
Vendor A is based on a “pay as you go” model, inviting you to enter a credit card and will bill you for the actual usage. Do you have any volume discount beyond a certain number of requests? On the other hand, Vendor B is on the prepaid model consisting of buying X number of transactions to cover your upcoming usage. How do you forecast your usage? Will you lose your remaining transactions at the end of the term?
It’s like comparing apples to oranges. Have you ever compared the pricing of the different location-based services platform? How do you compare a map load session and a map tile transaction? How do you figure out how many tiles your user will consume or how many keystrokes for each fast-completed address in your search box before your application goes live?
|What is the anticipated usage for this application? Less than 125,000 billable transactions per calendar year qualify for limited website and mobile app terms. More than that, you will need a Bing Maps Transaction subscription license for the number of billable transactions that will be used.||How many credits will you need to perform specific transactions or store data? For geocoding, you will need 40 credits per 1,000 geocodes||Monthly volume range (price per thousand) 0 – 100,00 calls = $5 100,001 – 500,000 = $4 500,001+ = contact sales|
|How are HERE Location Services transactions counted? For 2D map tiles, satellite tiles, or traffic tiles services, One Transaction is counted for every 15 Requests||Monthly Map Loads for Web (cost per 1,000) Up to 50,000 = Free 50,001 to 100,000 = $5 100,001 to 200,000 = $4||Buy a set number of credits per month Forward Geocode Premium= 1 credit = $0.01 per request Forward Geocode Advanced= 0.5 credit = $0.005 per request Forward Geocode Basic= 0.1 credit = $0.001 per request|
What is the anticipated usage for this application?
Less than 125,000 billable transactions per calendar year qualify for limited website and mobile app terms. More than that, you will need a Bing Maps Transaction subscription license for the number of billable transactions that will be used.
How many credits will you need to perform specific transactions or store data?
For geocoding, you will need 40 credits per 1,000 geocodes.
Monthly volume range
0 – 100,00 calls = $5
How are HERE Location Services transactions counted?
For 2D map tiles, satellite tiles, or traffic tiles services, One Transaction is counted for every 15 Requests
Monthly Map Loads for Web
Up to 50,000 = Free
Buy a set number of credits per month
Forward Geocode Premium=
Have you noticed that each vendor has their own way of presenting their pricing? In order to break through the noise Korem has in-house methodology for comparing solutions in order to recommend the best solutions for your use case.
In addition to usage, implementation may greatly impact the pricing. Implementing best practices and optimization can save you a significant amount of credits. Depending on the use case, the optimal implementation may be different. Here’s a quick example: by default, the Google Places API returns all attributes. Do you really need opening hours and Google reviews? If that’s not the case, you would be better served by requesting only the fields you need in order to avoid extra fees. Moreover, some vendors will charge you for certain capabilities, such as type-ahead, where others won’t.
The project: Avoid an unexpected journey
Nowadays it is very easy to use location-based services to do proof of concept and development. People often forget that IT and procurement need to be included in the process. So, do yourself a favor and involve those guys sooner than later and you’ll be on right track to a project on time and on budget.
As you can see, choosing the right platform is not a linear process and implementing it optimally is often trickier than it appears. At Korem, we have managed a lot of projects involving location-based services and too often, we heard “if I had called you before, I would have saved a lot of time and money”.