When reading documentation, looking at a huge array of class names, best practices, and other directives can become overwhelming. If you’re taking a first dive into developing with location-based-services (LBS), starting with web development can prove to be a familiar entry point when incorporating a new tool into your existing skillset.
In this article, I’ll break down a few potential use cases of different objects presented in the documentation for the TomTom Maps SDK for Web, to shift this dev ocean into a few more bite-sized coding topics to snack on. We’ll go through uses of classes GeolocateControl, Evented, and IncidentMarker, and how these might be helpful to be aware of as you start interacting with TomTom Maps.
If you were to go through the Maps SDK documentation sequentially in terms of objects you’ll use during your initial setup, you’ll most likely come across Evented first.
Evented is an object response class, with a type and listener. This type can be on, off and once. Adding a listener via “on” will designate the function called when the event is fired. This is inverted to remove the listener via “off”. “Once” will add a listener called only once, as you’d predict, for a specific event.
GeolocateControl is where you can begin to get creative. This object extends Evented, and allows a user to generate a button to provide the location tied to a browser in one click. This is enabled in a number of ways:
- The parameter trackUserLocation is either true or false.
- If trackUserLocation is true, we are tracking the user’s location actively, and the created button will then have the ability to toggle and view the consistently updated location.
- If trackUserLocation is false, we are not given permission to read the browser’s location in real-time. The browser’s location will still be used once when the button is pressed, by the map will not update as the user moves.
Note that not tracking the user’s location continuously is likely less acceptable for mobile browser environments and general mobile use cases, as users are probably relying on real-time wayfinding. Thus, trackUserLocation being set to false is really only appropriate (if at all) for desktop uses, of which there may be fewer.
Following this, GelocateControl itself has three possible states: Active, Passive and Disabled. Similar to the interactions above with trackUserLocation, active state allows the camera view to adjust and view changes in the user’s location as they are updated, while passive state updates the location separately, not attached to and not updating the camera view.
How will I use this?
On to the best part: what you can build! You have a lot of options when deciding how to use the Maps SDK to your advantage. Let’s look at a few uses that are good examples of Geolocate Control’s function.
The main use case to consider for browser tracking (either live or static), is tracking the real time movement of a person or object for specific reasons other than traditional turn-by-turn direction.
Safety-related location monitoring would involve you, with specific permission, viewing an actively updated location.
If you’ve ever been to a music festival and tried to find your friends while wandering around throngs of glittery, flamboyant party goers who all look alike, you already have another use for this class. You could easily implement a peer-to-peer location application within a specific area range that you define – taking into consideration a mobile optimized browser-based login as opposed to a native application.
The same could apply for other outings in a large, natural area, such as biking and hiking groups with multiple arrival times, trying to coordinate with the rest of the participants on where to meet, where to travel, and how to check-in if someone loses their way.
Instead of using multi-stop routing on your browser, you can implement trip planning based on real locations of your friends and family to calculate truly accurate arrival times – no more “I’m on my way” followed by, “Ok I’m ACTUALLY on my way!”.
GeolocateControl has some familiar uses, so essentially this section is to help you outline when you’d interact with this class, should your mapping application ever be focused on location-finding of individuals via a web browser.
If you’re more interested in collaborative map building, the next section will help clarify how you’d get started.
There is one last object that you might be most interested in when ideating on things to build. IncidentMarker allows you, the developer, to customize the visuals and create several varieties of incident-indicating map points. Size, opacity, CSS class passing to inner and outer containers, are all editable aspects, as is the use of customElementCallback for function passing to render a totally custom HTML element as your marker.
Thus, using custom HTML elements, one can use categorical icons to further personalize their map, as well as icons which indicate the density of an available option -- that is, icons which show a number to indicate more than one museum, restaurant, apartment building, or other attribute, is available in the given space.
Why would I be using IncidentMarker?
You can use IncidentMarker for any project in which you want to visually render events on a map!
If you create an application in which you allow other users to access the map with their own account or shareable viewing capability, you could build a space in which users can log the safety of areas – indicating unsafe areas or incidents by placing their own marker. This would effectively build a density map for the affected area – university campuses are a good example of impactful places for this feature.
Other applicable places are bike paths, especially in parts of Europe, where bike accidents can be mapped from bicyclist reporting. In an alternate space, favorite scenic areas can also be easily found by shared users with incident markers, which can then be used to heatmap nature trails, parks, and other recreational areas for good photo spots and the like. This use could even provide the basis for polls and ranking systems for different popular areas.
IncidentMarker is a straightforward way to add personality to your mapping project, with customization and a few more diverse use cases.
There is a lot more to the Web SDK documentation than found here. For people new to using the SDK, this should help gear you up on what to expect as you start developing, as well as give you a creative jump start to what you can build with web-based map services.