DEV Community: Shannon🦖

The Future of Mobility is Electric

Shannon🦖 — Fri, 14 Aug 2020 20:48:51 +0000

I bought my first plug-in hybrid car last year. It's a Cadillac ELR, if you're a car-person, you know that ultimate car-guy, Doug DeMuro called this car "awful". I bought this used car for my daily commutes. While this car has been an awesome daily driver, the biggest issue we have is finding charging points that carry it's 2015 plug type.

When TomTom launched it's EV Mobility Kit last year, one of it's newest features was enabling developers to build apps that show compatible nearby charging stations - which would help alleviate my weekly hunt for a charge. This post originally published on TomTom's Developer Portal by Product Marketing Manager, Julija Babre & brings to light the importance of developing for electric vehicles

What the EV network looks like

The future of mobility is connected, autonomous, shared and electric. This change is happening now.

The number of Electric Vehicles (EVs) on the road is increasing every year. The International Energy Agency estimates that 1.98 million EVs were sold worldwide in 2018, bringing total EVs sold to 5.12 million. Sales of EVs increased by 64% from 2017 to 2018.

Apart from being more present on the roads, EVs are becoming increasingly affordable. Bloomberg New Energy Finance forecasts that electric cars will be as affordable as combustion-powered vehicles in the next six years, even without subsidies or incentives.

Now that drivers are considering the switch to electric, some common questions arise: is EV range sufficient to get to my destination? Is the charging infrastructure developed enough?

In most of the US and Europe, the answer is yes. Research from MIT shows that the range of EVs available today is sufficient to cover 87% of average user trips. At the same time, charging infrastructure is evolving quickly, supported by many government programs worldwide.

For example, the state of California has an ambitious goal of having 1.5 million zero-emission vehicles (ZEV) on the road by 2025 and 5 million by 2030, with an associated infrastructure goal of 250,000 ZEV chargers by 2025.

Although conditions seem optimal for EV adoption to take off, currently the adoption rate remains relatively low.

One of the main reasons for this is the psychological barrier of range anxiety — the fear of being stranded on the roadside when the EV battery runs out, with no way of charging up nearby. Electric vehicle-specific routing and easy access to charging infrastructure are two of the many ways location technology can help developers alleviate range anxiety for drivers, and increase adoption of EVs around the world.

How Developers can help electric vehicle drivers

Many drivers depend on mapping and routing applications to find the locations they’re interested in, such as restaurants, stores, or their friend's new house. They expect routing and mapping applications to get them to the destination quickly. Adoption of EVs creates both a routing challenge for drivers and an opportunity for developers, as we touched upon in the previous section.

EV drivers have unique needs when it comes to mapping and routing applications. To name a few, EV drivers require:

Routing applications that take into account their vehicle’s charging behavior.
Routing applications that won’t guide them to a place where they’ll be left stranded on the side of the road, with an empty battery and no opportunity to charge.
Knowledge of their specific vehicle’s range to determine which destinations they can reach and when they need to charge.
The ability to maximize how far they can drive on a single battery charge.
An easy way to find compatible and available charging stations easily wherever they go.

Current mapping applications don’t always answer these EV-specific needs and worries. Consequently, there’s a massive opportunity for developers to build mapping and routing applications specifically for EV drivers. What’s more, developers need easy access to the right tools to build these unique applications.

Building effective apps for EV drivers

To build a reliable route planner that fits EV drivers’ needs, developers must use location technology that can calculate routes taking into account the charging behavior and other parameters of the electric vehicle, traffic, and proximity to nearby charging stations.

Let’s look at a few ways that location technology can make it easy for developers to build apps for EV drivers.

Nearby charging stations

While out and about, one of the most common things an EV driver wants to know is whether there are any charging stations nearby or on their way that are compatible with the driver’s vehicle and not currently in use. This information is crucial for EV drivers to effectively use their electric car on a daily basis as well as for longer trips.

Today, developers have the opportunity to add this to any app they are building for EV drivers. If drivers can’t get this information from your app, they’ll have to get it somewhere else — and may stop using your app entirely.

Daily Routing and Reachable Range

For most EV drivers, location app usage revolves around daily routing, which does not require more than one charge. When planning typical trips, EV drivers focus on traveling within their vehicle’s reachable range, finding energy-saving routes to maximize battery life, and occasionally finding available recharging locations. EV drivers usually charge at home and are comfortable using their car for short trips and charge while at home or at work. They’re much more reluctant to take their EV on a long journey unless they can plan it carefully.

The TomTom exclusive eco-routing features — available in the TomTom Routing API — enable EV drivers can take the most energy efficient routes. The Routing API's Calculate Reachable Range feature provides the functionality developers can use to show EV drivers how far they can go on a charge. Calculate Reachable Range includes the ability for developers to specify precise energy budgets and detailed Electric Consumption Models.

With these features, location and routing apps can tailor results to EV drivers' specific vehicles and situations, whether they're starting from home with a full charge or planning the next stop on their daily travels. These routing features, focused on the needs of EV drivers, lay the course for confidence in planning longer trips, where EV drivers feel more preparation is needed, experience more range anxiety, have greater need for knowing exactly when and where to stop to charge and for how long.

Long Distance EV Routing

One area where EV drivers face significant challenges is planning longer trips — further than their EV can travel on a single charge. Planning such trips is tricky — drivers don’t want to stop more often than necessary, but also don’t want to end up stuck on the side of the road with a dead battery.

One critical difficulty EV drivers face compared to traditional car drivers is that they must do more planning and preparation before going on longer trips. Range anxiety comes into play on such trips. The driver will ask themselves questions like:

Can I reach my destination if I go with an EV?
Where should I stop to charge, and for how long?
Is there anywhere for me to recharge my vehicle when I arrive?
Which compatible and available EV charging stations can I reach from my current location?

Developers should aim to create apps that can answer all of these questions.

Developers can help by creating applications that give EV drivers confidence to take long trips without feeling any range anxiety. By considering the characteristics of the driver’s vehicle, the availability of compatible charging stations en route, and the energy requirements of all potential routes, new applications can take the worry out of long-range EV journeys.

Even better, these apps could tell users about restaurants and amenities near the charging stations they stop at, so they can make the best use of their time while the EV is charging.

What developers need to build apps for EV drivers

Creating applications tuned to the needs of EV drivers requires lots of data — not just the charging station locations, but also the availability of chargers updated dynamically in real time. The limited number of charging connectors at a location coupled with the length of time the charging point is in use (minimally 30 minutes, but possibly far longer) makes this information critical. The driver wants to know whether they can charge the EV right now.

Keeping this information up-to-date requires periodic updates of source data and the ability to incorporate estimated time of arrival (ETA) into the calculation. Other information, such as operating hours and plug types, is also necessary. All of this information must be maintained and structured to answer driver queries rapidly and accurately.

Beyond this, you’ll also need to understand how road characteristics such as steep uphill grades and traffic conditions can impact electric vehicle range.

It is difficult and expensive to acquire and maintain this kind of information on a global scale. It is even more challenging to use this data and develop algorithms that support EV driver-specific needs and use cases. While there are many start-ups and larger companies working in the field of electric mobility, to do it effectively, developers need access to data and tools to make their effort reach the expected effectiveness levels.

What's available to Developers today

The TomTom Developer Toolkit for Electric Mobility is specifically designed to provide the services developers need to take advantage of the opportunity created by the explosion in EV popularity.

The Developer Toolkit for Electric Mobility contains new APIs that — when combined with TomTom’s existing location APIs — make it quick, fun, and easy for developers to create apps for EV drivers.

Let's take a look at the new APIs that can make life of a developer working on electric mobility apps much easier.

Long Distance EV Routing API

While the Routing API calculated the most energy efficient routes and the reachable range, the Long Distance EV Routing API helps developers quickly plan long trips for EV drivers. By taking electric vehicle characteristics, traffic, and the charging station infrastructure into account, it enables developers to easily get routes that include optimized EV charging stops along the way with a single API call.

EV Charging Stations Availability API

With the TomTom Search API, developers can already find locations of EV charging stations in over 53 countries. The new EV Charging Stations Availability API goes a step further: it is now possible to check the real-time availability status of individual charging stations per connector type in 14 countries. Instead of just telling the EV drivers which charging stations are nearby or along their way, you can tell them which charging stations are compatible with their vehicle and are currently available for use.

Next Stop: Building Apps for EV Drivers NEXT STOP: BUILDING APPS FOR EV DRIVERS WITH TOMTOM

EV drivers present new and unique challenges for mapping application developers. They also offer a huge opportunity. It’s not every day that a new and rapidly-growing market appears that is hungry for new apps where location is key.

The TomTom Developer Toolkit for Electric Mobility provides the APIs and SDKs that developers need to create amazing apps without needing to tackle challenges like finding charging station availability, planning energy-efficient routes, and ensuring a driver’s battery will not run out at the most inconvenient moment and location. Let TomTom handle the hard parts of building for EV drivers so that you can focus on what’s most important: delivering apps that EV drivers will love and use every day!

Understanding Map Tile Grids and Zoom Levels

Shannon🦖 — Tue, 08 Oct 2019 23:02:17 +0000

How do you take a round object and display it accurately on a flat surface? We'll explain how TomTom maps displays mapping data via map tiles and zoom levels.

INTRODUCTION

How do you take a round object and display it accurately on a flat surface? This is a question map makers and cartographers have been grappling with for centuries. And it remains an issue for mapping service makers as well.

To provide quality mapping information you can use in devices and applications, TomTom's location services employ a Spherical Mercator projection of the earth's surface to create the underlying map representation used by the services. The map data is further delineated by zoom levels and tile grids that provide the exact visual representation you need to display a map on a web site, mobile map or other devices.

In this article, we'll explain:

How maps are designed
How map data is represented in the TomTom Maps API in tiles
How zoom levels affect what information appears on map tiles

MERCATOR PROJECTION

With growing awareness of the Earth’s nature, early cartographers faced a problem. While most maps were rectangular, the Earth was approximately spherical. They required a way to project coordinates from a three-dimensional ellipsoid onto a two-dimensional rectangular plane. Technically, the Earth is an ellipsoid bulging slightly at the equator.

In 1569, the Flemish cartographer Gerardus Mercator proposed a mathematical basis for this projection. While many other projections also exist, this quickly became, and remains, the most popular.

With any such projection, some distortion is unavoidable. In the Mercator projection, geographical features further from the equator are exaggerated in size. For example, Greenland appears to be of a similar size to Africa. However, Africa is actually more than 14 times as large (by area).

The map below shows the apparent relative sizes of Greenland (left) and Africa (right) on a map using the Mercator projection. The orange area in the center of Greenland is its relative size without the distortion caused by Mercator projection.

The Mercator projection also has the disadvantage that it is not possible to represent the North and South poles since these would be nearly infinite in apparent size. For this reason, most Mercator maps omit approximately five degrees of latitude at each pole.

The Mercator projection has the advantage that it preserves rhumb lines. When drawn on the map, they are straight lines. Rhumb lines are commonly used for nautical navigation. They are lines of constant bearing with regard to magnetic North.

WGS 84/PSEUDO-MERCATOR

Additional requirements arose with the wider availability of web-based mapping data. Since maps now allowed the ability to zoom and pan, the industry collaborated to establish a de facto standard for projection that better supported these features.

In 2005, they introduced a new projection that is based on the Mercator projection. It introduces the concept of zoom level. It also simplifies the equations to use a spherical approximation for faster calculations.

This new projection presents similar distortions to the Mercator projection for geographical features further from the equator. It also has similar limitations with regard to representing latitudes near the Earth’s poles. Unlike the Mercator projection, it does not preserve the rhumb lines used for nautical navigation.

This projection is officially designated by the European Petroleum Survey Group as EPSG 3857 and named “WGS 84 / Pseudo-Mercator”. It is also commonly referred to as “Web Mercator” and sometimes as “Spherical Mercator”.

ZOOM LEVELS

The TomTom Maps API utilizes the concept of a “zoom level” to support the display of increasingly more detailed maps. The zoom level is an integer that specifies the level of detail to display on the map, with larger integers resulting in greater levels of detail.

Raster maps allow zoom levels that range from 0 through 20. Vector maps include two additional levels of zoom: 21 and 22.

TILES

To implement zooming, TomTom divides the map into equal-sized square tiles. At a zoom level of zero, the map of the entire Earth fits onto a single tile.

With each increment of zoom level, every tile is divided into four equally sized tiles. The result is a map that is four times as large with a similar increase in detail.

The number of tiles on each side of the map (horizontal or vertical) doubles with each increase in zoom level. For this reason, the number of tiles on a side is easily calculated as 2zoom-level. To calculate the total number of tiles on the map, simply square that value: 2zoom-level x 2zoom-level.

Until this point, we’ve focused on understanding how the size of the map and the number of tiles increases with zoom level. Next, we’ll consider how the level of detail also increases with zoom level.

The Empire State Building is located at 350 Fifth Avenue, New York, New York, USA at latitude 40.74816° N and longitude 73.985° W. The diagram below helps to understand how detail increases with zoom level. In this diagram, we show the single tile, from each zoom level, that contains this building.

By the time we reach zoom level 17, the Empire State Building occupies a considerable portion of a single tile. With further zooming, to level 18, multiple tiles are required to represent the building.

Fortunately, the TomTom Maps SDK for Web is not quite so limited. It is entirely capable of displaying portions of a tile, such that the building appears centered on the map.

For example, using the TomTom Maps SDK for Web, we can find the position of the Empire State Building by writing code for a simple search like the following.

tomtom.setProductInfo('<your-product-name>', '<your-product-version>');
tomtom.key('<your-tomtom-API-key>');

tomtom.fuzzySearch()
  .query('Empire State Building')
  .limit(1)
  .go(function(response) { showMap(response[0].position); });
This code searches for the term “Empire State Building” and limits the response to a single result. It then calls the function “showMap”, passing the latitude and longitude of that single result as a parameter.
function showMap(center) {
  var map = tomtom.L.map('map', {
    center: center,
    zoom: 18
  });
}

The code for the “showMap” function is very simple. It creates a map that is placed in the HTML element with the identity “map”. It centers the map on the position returned from the earlier search and sets the zoom level to 18.

In a web browser, the resulting map appears similar to the following.

While it may not appear so, this map is still tile-based. In this case, the TomTom Maps SDK for Web greatly simplifies our interaction with the underlying Maps API. The Maps SDK for Web requests each of the individual map tiles and selectively hides portions of them to center the search result. It also overlays copyright information and a user interface to allow the user to change the zoom level.

If we were to show the tile boundaries and the hidden portions of each tile, the map would appear approximately as follows.

The complete source code for the HTML file used in this example appears below.

This example assumes that the TomTom Maps SDK for Web has been downloaded from TomTom Maps SDKs and that the HTML below has been edited to provide a valid TomTom API key.

<!DOCTYPE html>
<html>
  <head>
    <title>Empire State Building</title>
    <link rel='stylesheet' type='text/css' href='sdk/map.css'/>
    <script src='sdk/tomtom.min.js'></script>

    <style>
      #map { height: 512px;  width: 512px;  }
    </style>
  </head>

  <body>
    <div id='map'></div>

    <script>
      tomtom.setProductInfo('<your-product-name>', '<your-product-version>');
      tomtom.key('<your-tomtom-API-key>');

      tomtom.fuzzySearch()
        .query('Empire State Building')
        .limit(1)
        .go(function(response) { showMap(response[0].position); });

      function showMap(center) {
        var map = tomtom.L.map('map', {
          center: center,
          zoom: 18
        });
      }
    </script>
  </body>
</html>

To learn more, check out the TomTom Maps SDK for Web functional examples on the TomTom developer web site. You’ll find examples of not just returning basic raster and vector map images, but much more detailed use cases including manipulating map layers, adding markers and more.

To learn more about mapping and Maps APIs, check out the TomTom Developer blog.

How to Add Traffic APIs to Your Location-Based App

Shannon🦖 — Thu, 19 Sep 2019 22:25:48 +0000

If you’re a developer, you probably already know why APIs are valuable—By integrating APIs into your project, you can greatly simplify and accelerate whatever you are building by taking advantage of solutions that have already been provided by industry leaders, and using the pre-existing code that they offer.

Traffic APIs are a great demonstration of the value of APIs for developers (not to mention end-users who can take advantage of API-powered traffic apps). Traffic APIs provide the building blocks for you to potentially craft better user experiences with real-time traffic data. You can build fun tools and applications and gain insight about traffic happenings.

TomTom is an industry leader in the realm of navigation, mapping, and traffic products, and continues to create influential, easy-to-use navigation systems. Over the years, the company has expanded its focus from device manufacturing to software development. And now, they have decided to share what they do best: advanced traffic information. TomTom produces innovative software and services and offers a comprehensive API that will allow you to retrieve detailed traffic information about an area.

In this article, we will dive into how TomTom’s Traffic API works and how we can leverage the Traffic suite of web services (which are based on the real-time traffic data from TomTom Traffic) to retrieve detailed traffic information about an area, which you can use for your web and mobile applications. We will be making use of some JavaScript with ReactJS, as well as bash scripting in the examples.

HOW DOES TOMTOM TRAFFIC WORK?

TomTom Traffic API is a cloud-based, real-time traffic monitoring information service that detects traffic on highways and secondary roads, and it works because of billions of anonymized traffic measurements (GPS traces or probe data) from around the globe. The service has existed for a decade, and the company has access to a lot of Big Data about where, when, and how people drive all over the world.

In order to provide this quality service, data is combined from traditional sources (e.g. road induction loops, traffic surveillance cameras), modern sources (e.g. data from millions of anonymous mobile phone users), and historical data. The information is then collated by TomTom data centers for further filtering and improvements before it gets distributed to its customers as relevant, real time traffic information, with updates sent every two minutes. The traffic data is reliable, accurate, frequent, and has wide coverage. A lot of details (e.g. traffic jams, road closures, delays) are provided, even for smaller roads.

With the quality of TomTom’s traffic data in mind, we can be confident about creating useful, reliable and high-quality applications through the use of their Traffic API suite, which is based on this data.

GETTING STARTED WITH TOMTOM AND THE TRAFFIC API

The Traffic API is a suite of web services that can let you to unleash your creativity by building user-friendly applications with real-time traffic data. The service is built with developers in mind, can be used via RESTful APIs, and has very wide market coverage.

The TomTom Developer Portal is where you’ll find everything you need to get up and running with this API. The first thing you’ll want to do is create an account on the portal. From the home page, enter your email address and click on the “Get a free API key” button.

Once you have signed up or logged in, create a new app to receive your API key. Applications require a name, and you’ll need to enable the APIs which the application needs to access. For this example, the product we’ll be using are the Traffic Flow API and the Traffic Incidents API. If you’re following along, select the Traffic Flow API and the Traffic Incidents API products and click on Create App.

The Traffic Incidents API provides accurate information about traffic jams, incidents, accidents, and delays surrounding an area that you can display on a map. The Traffic Flow APIs provide information about observed speeds (current, freeflow) and travel times for specific road networks.

This article focuses on how to use the TomTom Traffic Flow and Traffic Incident APIs, but developers also have access to Web and Mobile SDKs which contain similar functionality. You can learn more about each of the SDKs from the following links:

Maps SDK for Web
Maps SDK for Android
Maps SDK for iOS

EXAMPLE USE CASE #1

Let’s find the location of a user and then display real-time traffic jams and incident data based on where they are. When the user is on a mobile device (even when they are just connecting to a website and not using a native app), you can ask for their GPS position. In this example, we will just locate the user based on their IP address.

We will be using the Traffic Incident Details API from the Traffic Incident API suite. The request URL for this API is in this format:

https://api.tomtom.com/traffic/services/{versionNumber}/incidentDetails/{style}/{boundingBox}/{zoom}/{trafficModelID}/{format}?key={API_KEY}&language={string}&projection={string}&geometries={string}&expandCluster={boolean}&originalPosition={boolean}

Let’s dig a little deeper into what each parameter means.

https://api.tomtom.com
traffic/services	// traffic service
{versionNumber}	// version of the service to
/incidentDetails	// incident details service
/{style}	// style of tile to be rendered
/{boundingBox}	// bottom-left latitude,
	bottom-left longitude,
	top-right latitude,
	top-right longitude
/{zoom}	// zoom level
/{trafficModelID}	// traffic model ID (default -1)
/{format}	// xml, json, jsonp
?key={API_KEY}	// API key
&language={string} .	// language of descriptions
&projection={string}	// type of coordinate system
	(EPSG900913 or EPSG4326)
&geometries={string}	// type of vector geometry added to
	incidents
&expandCluster={boolean}	// send clustered points
&originalPosition={boolean}	// return original position of
	incident and the one shifted to
	beginning of traffic tube

An example response based on this request:

{
"tm": {
    "@id": "1537875895566",
    "poi": [
        {
            "id": "europe_CLUSTER_9_-1546746781",
            "p": {
                "x": 11.368265,
                "y": 48.002922
            },
            "ic": 13,
            "ty": 1,
            "cbl": {
                "x": 11.28824,
                "y": 47.969362
            },
            "ctr": {
                "x": 11.44829,
                "y": 48.03646
            },
            "cs": 13,
            "l": 27210
        },
        {
            "id": "europe_HD_DE_TTR131344535899136",
            "p": {
                "x": 11.237004,
                "y": 48.082583
            },
            "ic": 9,
            "ty": 1,
            "cs": 0,
            "d": "roadworks",
            "c": "new roadworks layout",
            "f": "Wörthsee (A96)",
            "t": "Germering-Süd (A96)",
            "l": 5840,
            "dl": 113,
            "r": "A96/E54"
        }
    ]
}

Now that we have a better understanding of how to consume the API, let’s try to build a simple app with it. We can use ReactJS to consume the API and manipulate the data like so:

INDEX.JS

import React, { Component } from "react";
import ReactDOM from "react-dom";
import publicIP from "public-ip";
import geoPoint from "geopoint";
import IncidentCategory from './components/incident_category';
import IncidentData from './components/incident_data';
import IncidentLegend from './components/incident_legend';
// Your API KEY can be hardcoded, but I recommend setting it as an env variable.
const API_KEY = '*****';
class App extends Component {
 constructor() {
   super();
   this.state = {
       error: null,
       isLoaded: false,
       trafficData: []
   };
 }
 componentDidMount() {
   publicIP.v4()
   .then(ip => fetch(`https://ipapi.co/${ip}/json`))
   .then(res => res.json())
   .then(result => this.getBoundingBox(result.latitude, result.longitude))
   .then(
       values =>
       fetch(`https://api.tomtom.com/traffic/services/4/incidentDetails/s3/${values[0]._degLat},${values[0]._degLon},${values[1]._degLat},${values[1]._degLon}/10/-1/json?key=${API_KEY}&projection=EPSG4326`)
   ) 
   .then(res => res.json())
   .then(
       payload => {
           this.setState({
               isLoaded: true,
               trafficData: payload["tm"]["poi"]
           });
       },
       error => {
           this.setState({
               isLoaded: true,
               error
           });
       }
   )
 }
 getBoundingBox(latitude, longitude) {
   const bboxValues = new geoPoint(latitude, longitude).boundingCoordinates(10, true);
   return bboxValues;
 }
 render() {
   const { error, isLoaded, trafficData } = this.state;
   let date = new Date();
   let currentDate = date.toDateString();
   let currentTime = date.getHours() + ':' + date.getMinutes() + ':' + date.getSeconds();
   if (error) {
    return 
        Error: {error.message};
   }
   else if (!isLoaded) {
       return  Loading...;
   } 
   else {
       return (
          Traffic Incidents
               {currentDate}
               Time: {currentTime}

COMPONENTS/INCIDENT_DATA.JS


import React from 'react';
const IncidentData = (props) => {
   const incidents = props.data;

   return (

           {incidents.map((el) => {  
               return (

                       {el["p"]["x"]}, {el["p"]["y"]}   // location
                       {el["l"]}                                    // length of delay
                       {el["d"]}                                   // description
                       {el["ic"]}                                  // type
                       {el["ty"]}                                 // severity

               )
           })}

   );
};
export default IncidentData;

More of the code can be viewed here.

For the second example use case for adding Traffic APIs to your app, please read the rest of this article on TomTom's Developer Blog.