GSE Blog 

Feature Overview

Places are, as the name implies, specific points on the map that have been saved to the user’s account in order to be accessed, referenced, visible, and/or utilized in combination with or by other features. Places can be actual places of interest, locations of significance, offices, homes, customer addresses, or even just reported positions that needed to be saved (for example: the exact location, date , and time where an incident occurred, a fishing hole, the exact location of a favorite hiking view, etc).

Once created, Places will be visible on the map view unless the user toggles them off, and whether visible or not, users will be able to use them with other features like Geofences, Alerts, Get Route, Waypoints, Trips, Journeys, Reports, and Shared Views.

Problem-oriented Design Framework

What is Problem-oriented Design?

Problem-oriented Design (POD) places emphasis on users and their specific needs when making UI and UX decisions in product design. Rather than building a solution in search of a problem, the POD framework employs proactive and reactive responses to actual problems in a given market. Anticipation of needs is a critical component of successful POD, but for the majority of POD casework, there is a well-defined problem with a determinate set of solution parameters from which a product manager can construct a strong and well-positioned product or feature.

The process of POD involves identifying the design scenario, which is typically a somewhat niche use case or user demand that has limited available solutions. From this design scenario, a product manager can define the goals of a successful product, and then create the set of product requirements necessary to deliver a working solution. These solution requirements can be any combination of must-have feature functionality, compliance measures, compatibility restrictions, cost considerations, and a multitude of other factors.

Each POD process results in a solution theory and product or feature proposal that includes success benchmarks and performance metrics that can be tested and iterated as necessary. Also included in POD solution theories is a viability assessment that will include analysis of efficiency, effectiveness, and investment requirements. Any product or solution borne of the POD process is one that can be expected to deliver on users’ needs in a way that makes sense and represents a suitable and comprehensive option for solving the design scenario.

Design Scenario for Places

Portal users need a way to store the following different types of information in an object that can be displayed on the map and used cross-functionally with other features.

• Points of interest
• Customer addresses
• Facilities locations
• Route origins, stops, and endpoints
• Specific reported positions or events
• Hidden information
• Incident details

Solution Requirements for Places

Places must be visible on the map interface, and will therefore require a specific, unique, and identifiable location attribute. The location attribute will be critically important for use with other features and almost all of the primary applications users will have for the Places feature, such as routing. For the types of data that users wish to store that does not have a location attribute, it will be recommended that the user identify a place on the map of little significance and use that location information to store the data.

Places must function as an object in the portal that can be used with other features.

Non-location Attributes of a Place must include, at a minimum, a Name, identifying iconography for display in the portal, the ability to have at least one photo attached, and at least one text input field with no data validation requirements.

Solution Theory for Places

The Places Feature is a very basic and essential core component of a tracking portal, but has some potential for advanced use cases and additional opportunities for increased leverageable return on investment if designed appropriately. Because of this, Places have been designed in a way that allows them to be viewed on the map and also used by routing tools because of a unique referenced location attribute.

In anticipation of users wanting to use Places to store additional information, such as one specific reported position of any Asset, or an incident pertaining to that Asset, Places has also been designed with plain text fields that can be used to store any kind of information, like dates, times, and descriptions of the position or incident. Additionally, the Places feature has been given the ability to host a photo so that any user with access to the Place can add photos for reference or access them when necessary.

Places have also been designed to include administrative security measures, which means they can be assigned to specific users and hidden from others. This allows Places to be storage objects for a number of different types of information with varying degrees of organizational sensitivity and clearance requirements. Access control of Places also establishes accountability measures that can be used in large organizations that have a number of levels of information security requirements.

Using the Places Feature

Getting Started with Places

Places can be created in a number of different ways, most of which involve using the portal’s Add Item module and selecting the Add Place option. Creating a place will require users to specify its name, location, and map interface display icon, and will give users the option to add other optional attributes as desired.

Add a Place - by Map

1. Open the Add Place form
2. Name the Place
3. Click the location you wish to store on the map interface
4. Select a display icon
5. Add any additional information you wish to store with the Place

Add a Place - by Coordinates

1. Open the Add Place form
2. Name the Place
3. Input the Lat/Lng of the location you wish to save
4. Select a display icon
5. Add any additional information you wish to store with the Place

Add a Place - by Address or Search

1. Open the Add Place form
2. Name the Place
3. Input the address or name of a well-known location, then click search
4. Select a display icon
5. Add any additional information you wish to store with the Place

Add a Place - by Upload

1. Click the Places module
2. At the top of the List Panel, click the Quick Actions (dot menu) button
3. Select Import Places
4. Follow the instructions on the form to upload and ingest a KML file

Add a Place - by Feature

Each reported position from any Asset will have the option to be saved as a Place. To create a Place from a position, click the position on the map to open its Information Panel. In the Quick Actions (dot menu) options list, users will find Add as Place, which will open the Add Place form with the location information pre-filled.

How to Use Places

Places can be accessed, viewed, edited, and toggled in the Places Module from the main navigation panel. Additionally, if their visibility is toggled on, Places will appear in the Live Mode and History Mode map views as well. Users can open any Place to interact with it from either of these two locations.

The most frequently-used tool with Places will be the Route Asset tool, which allows users to set the Place as an endpoint on a route, and then select any Asset in the portal to generate the route between the two. The easiest way to route an Asset to a Place is to open the Place from the List Panel in the Places Module, click the gear icon to expand the Details Panel, and click the Route Asset option from the tools panel. This will open the Get Route Tool with the Place populated, and a drop-down box to select the Asset to be routed. Users will have the option of routing via roads or by direct path (air or water travel).

Other Place-based routing tools can be found in the Quick Actions (dot menu) on the Information Panel for any Place. These options include Route Asset, which will open the same form as above, as well as Route From and Route To. These options will open a separate tool that is used to generate a route to or from a place whose other endpoint is not the location of an Asset. This allows users to generate, for example, routes between multiple Places, or routes to a Place from an airport, or a number of other use scenarios. Users can also select Measure Distance To, which will open the Ruler Tool with the Place populated as one of the endpoints for a straight-line distance measurement.

Finally, users have the ability to use Places as a filter in the creation of Reports. Certain Reports, like the Asset Location Report, give users the option to filter the inclusions according to which are near or not near a particular Place. This can be particularly useful for large ecosystems trying to isolate the positions of Assets that might be compromised by an emergency situation in a given location. It is also a critical component of dispatch or logistics operations that sync operator location data with the locations of customers.

Additional Usage

Advanced usage of Places involves mostly the data storage capabilities, and the potential to hide information in the portal so that it is available to select people. Because the only mandatory attribute of Places is a location on the map, using them to store special information can be a good way to hide things in plain sight and make them available as necessary to other users. The Description field can be used to store any combination of things like special data, emergency protocols, and gate access codes.

Users can configure their portals to gather data from external sources in a number of ways, including map layers and data feeds, and can then create places from those data sources. This functionality can be used in disaster/emergency scenarios (to create a Place where an explosion happened and identify all nearby assets that need to be evacuated), logistics management (create places for pickup and delivery locations), as well as commercial and emergency dispatch applications.

Leveraging the Places Feature

Maximizing the ROI of Places

Asset Routing is a major feature of any top tier telematics visualization platform, and represents one of the highest value feature sets in terms of return on investment. Giving asset managers the ability to route any asset to any location is a critically important management tool, and the Places feature is a massive component when it comes to increasing the efficiency of those processes and eliminating the risk of routing mistakes. When routing Assets, being able to select a validated location from a list of destinations saved to the portal as Places will save time and give managers the peace of mind that there won’t be any errors related to identifying the correct destination.

While routing is one of the most ubiquitously used ways to extract ROI from places, some customers have also employed Places to store critical information in the portal that can be accessed by users during an emergency or as part of a standard security measure. These users will create a Place in the portal, and then either attach a photo that includes the necessary information, or include the information in the description of the Place. Because Places have the ability to be user-restricted, Administrators can give access to this information only to specific users and only when they need to do so. This use case has been employed by a number of clients as part of a fail-safe system in which a triggered event directs a permitted user to open the indicated Place to find protocol information.

Sample Application Scenario

Using Places in Emergency Situations

Sometimes emergencies occur that require an immediate response to the affected area, and asset managers need to be able to account for all of their Assets and personnel that may have been affected, while simultaneously sending help whenever necessary. Being able to convert the reported position that came with the Emergency alert to a Place and run a real-time Asset Location Report can accomplish the first goal of knowing immediately which Assets and personnel should receive a pushed status request from the portal. From there, users can route other Assets to that location to provide immediate support.

For example, if an accident like a rollover occurs with a skidder during a hillside logging operation, it can involve any number of other Assets, including light vehicles and heavy machinery (like a cable yarder). In addition to the skidder operator, a number of other workers could be in the area of the accident, and their safety would be in question as well. For this type of accident, it would be important to be able to push a status check to every operator and worker with a reporting device whose most recent location was near the Place where the accident occurred. Because of the remote nature of logging operations, emergency services can be hours away, and site managers may need to route light vehicles from other areas on the site to the Place where the accident occurred and then to escort any injured persons to another location where they can meet with a medevac crew. All of these operations could be controlled and managed from a location with reliable communications and pushed to field Assets.

Places perform a number of essential tasks as storage units for Locations and other information in the portal, but in times of emergency, can be a critically important tool to the safety and security of personnel as well. Understanding the full range of capabilities granted to users by this feature set can, in some situations, save lives.