Do you have the correct configuration values?
In order for PWMapKit to successfully retrieve building assets from the server, your application identifier, access key and signature key must be correctly provided in the call to
Is the building identifier correct?
The identifier listed in the MaaS portal application should be used in the call to
Has the application availability been properly set for the given venue?
The application availability has to be set at the venue level. To check and set the application availability navigate to the venue in MaaS portal and tap the Edit Venue button. You should see a list of applications with check boxes. Ensure that your application checkbox is checked.
Have you checked the route in the MaaS portal?
Make sure that your points of interest and waypoints are connected by segments in the portal application.
Are you creating an accessible route?
If so, then it's possible that one of your endpoints is inaccessible or that the two endpoints are not traversable using only accessible points.
Have you cleared your cache since making changes online?
The map will cache building resources loaded from the server in order to work in offline situations. If you have recently made changes to the data online, you may need to clear your local cache and reload the building.
Have you checked to ensure your floor ID mapping is correct?
The blue dot will not be displayed on the map if it is unable to convert between the floor level reported by your location manager and the Phunware-specific floor identifier. These values are provided to the indoor location manager in a mapping dictionary.
Have you registered your location manager with the map view?
In order for the map to perform location tracking and display a blue dot, you must register an indoor location manager with the map view. This can be done by using a location manager that conforms to the
PWLocationManagerprotocol in your call to
Is your route snapping tolerance set too low?
In areas with excess interference or poorly performing location services, the user’s blue dot may not stay snapped to the route as expected. Increasing the route snapping tolerance may solve this issue.
Is there adequate location services coverage in the area?
This issue is most likely caused by an excessive delay in receiving an updated location from the location manager. The SDK will immediately switch the floor upon learning of a newly reported location on that floor, so make sure that the problem isn't related to interference or coverage.
There are two instances in which a wall or other immovable obstacle is traversed by a route or blue dot:
Is the route being drawn through a wall?
If yes, there are two possibilities: 1. The closest waypoint to a route endpoint is on the opposite side of a wall. In this case, adding additional waypoints to the correct side of the wall will likely solve the problem. 2. There is a segment defined on the server between two points that traverses a wall. In this case, the defined segment should be considered invalid and removed from the server through the portal interface.
Is the blue dot being drawn on a wall?
This is likely due to inadequate indoor positioning information. The blue dot is displayed based on information provided by a location manager and can be erroneous in areas with lots of interference.
Are zoom levels enabled?
When zoom levels are used, a point of interest may not be visible until the user has zoomed in far enough. In addition, it may disappear again after zooming into a certain level. In other words, points may be shown or hidden based on a specified range of zoom levels.
Have you asked the map to hide them?
The map can hide building annotations based on annotation identifier. Once they have been hidden, you must ask the map to show them again in order for them to appear.
Is the point active in the portal application?
Points can be made inactive on the server for maintenance or staging purposes. Any such point will not be loaded on the device at all.
Is the indoor user tracking mode set to follow or follow with heading?
In order for turn-by-turn maneuvers to switch automatically based on the users indoor location the user must be in follow or follow with heading mode.
Is there adequate indoor location coverage in your facility?
Turn-by-turn maneuver switching fidelity is largely related to indoor location fidelity. If you facility has areas of poor indoor location coverage that will adversely affect automatic turn-by-turn maneuver updates. This
ON THIS PAGE