Advanced routing features (beta)

Advanced routing features are currently under beta. To request access, email support@proximi.io.

Availability

In the next version of the wayfinding editor, you will not have to delete paths or POIs in order to exclude them from the wayfinding setup. You will be able to mark them as unavailable in the editor / API. All paths and POIs generated are available by default. Select the path or POI and toggle off "Available" on the right-hands side menu. Unavailable paths are visualized with a red icon on top of the path.

If you are using API calls for generating paths/POIs, determine availability by defining "available" attribute under properties as true (available) / false (not available). The property is optional.

"properties": {
    "available": false
  }

When requesting routes through API or JS library, unavailable paths are avoided by default.

Accessibility

You will also be able to determine, if a path is not accessible for wheelchair users, prams or visitors with other mobility limitations. This characteristic is only available for paths. All paths generated are accessible by default. Select the path and toggle off "Accessible" on the right-hands side menu. Unavailable paths are visualized with a dashed line.

If you are using API calls for generating paths, determine accessibility by defining "narrowPath" attribute under properties as true (not accessible) / false (accessible). The property is optional.

"properties": {
   "narrowPath": true
  }

When requesting routes through API, use the parameter

When using the JS library, unaccessible paths are avoided when you request an accessible route. In the sample JS project, unaccessible paths are avoided, when you select "Use elevators".

Unidirectional paths

You will be able to determine, if a path can only be walked to one direction. This characteristic is only available for paths. All paths generated are bidirectional by default (can be walked to either direction). Select the path and select the correct direction on the right-hands side menu. The options are "unidirectional" and "unidirectional-opposite". The direction that the route is unidirectional to is based on the way the path was generated (which coordinate is the starting one and which the end one). It is best to just test to find the right setting. The directionality is visualized with arrows on the map.

If you are using API calls for generating paths, determine accessibility by defining "bidirectional" attribute under properties as true (both ways) / false (only one way). Also define "swapDirection" as true/false to determine which direction the path should be taken. The property is optional.

"properties": {
  "bidirectional": false,
  "swapDirection": false
}

When requesting routes through API or JS library, directionality is taken into account by default.

Working hours

You will be also able to determine opening times for paths and POIs. The use case for working hours for paths and POIs is slightly different.

Paths

All paths are open around the clock by default. If there is a need to close some paths earlier than others (for example due to one entrance being open later than others), you can do that by determining working times on the editor.

Times should be determined using the 24-hour clock. The times are referring to the time of the end user device utilizing the wayfinding. So you don't need to worry about time zone differences or summer/winter time changes. However, you should consider the fact that a user may be previewing the routes before their visit, without realizing that time-based limitations exist. We recommend communicating the the user, in case you use time-based logic in the routing.

If you are using API calls for generating paths, determine accessibility by defining "_workingHoursEnabled" attribute under properties as true (limitations exist) / false (no limitations). Also define "workingHours" for each weekday. Note that the first day of the list is Sunday.

"properties": {
"workingHours": [
[
"14:00",
"22:00"
],
[
"08:00",
"16:00"
],
[
"09:00",
"17:00"
],
[
"10:00",
"18:00"
],
[
"11:00",
"19:00"
],
[
"12:00",
"20:00"
],
[
"13:00",
"21:00"
]
],
"_workingHoursEnabled": true,
}

When requesting routes through API or JS library, working hours are taken into account by default.

POIs

The way opening times are determined for POIs is the same. However, with POIs the opening times are not used to limit their visibility on the map or availability in the search by default. Opening times are visualized in the JS sample project in the POI details view.

Event editor

As an additional new feature, the platform allows you to manage items on top of the map based on calendar date. By default all items on added on the editor are always shown. This feature is available both for paths and POIs.

Manage availability by calendar date by selecting the POI or path and clicking on "Event editor". By clicking the starting and ending dates, a calendar pops up, allowing you to select the right dates.

The starting and ending dates are included in the time span. You can preview your setup by changing the date on the top of the editor view:

If you are using API calls for generating paths/POIs, determine availability by defining "dateStart" and "dateEnd" attributes under properties. The dates should be determined in Unix time in milliseconds. The property is optional.

"properties": {
      "dateStart": 1693519200000,
      "dateEnd": 1696111199999,
}

When requesting routes through API or JS library, paths that are not available during the current date are avoided by default. When using the Web SDK, POIs not available during that date are filtered out from the map and search by default.