Determine faster / cheaper / easier route from route search result

We will introduce an example of determining the "fast, cheap, and easy" route by using the route search response. Since "Ekispert API" does not have a function to return the judgment result, it is necessary to implement a way to let the customer make a decision on their application. Since we think the kinds of icon you want to display will differ depending on the app, please take a look for your reference.

※Sample image (Ekispert for iPhone)

Related URL

Procedures

1. Perform a route search

Route search will commence.

GET /v1/xml/search/course/extreme?key=your_access_key_here&viaList=22849:23019
<ResultSet apiVersion="1.26.0.0" engineVersion="201605_02a">
<Course searchType="departure" dataType="onTimetable">
<Route timeOther="6" timeOnBoard="7" exhaustCO2="105" index="1" exhaustCO2atPassengerCar="806" distance="48" timeWalk="0" transferCount="1">
<Point index="1">
<Station code="22849">
<Name>中野(東京都)</Name>
<Type>train</Type>
<Yomi>なかの</Yomi>
</Station>
:

simple route searchbus-only route search by average wait timeroute search by average wait timeallow searching, however, usingroute searchallows a greater range of search conditions.

Search condition point 1

Increasing maximum search count (searchCountParameter) and maximum answer count (answerCountParameter), allows for sorting many options (routes).

※Increasing maximum search count and maximum answer count has a considerable effect on response speed.

searchCount=20&answerCount=20

Search condition point 2

Sort classification If used well, some application-side processing Optional. Sort classification's default value is "EkiSpert" search order, so as long as nothing is designated in Sort classification, Performing judgment of "fast" route Optional.

sort=ekispert

Search condition point 3

Regardless of the value of sort classification , route search on "Ekispert API" searches the number of routes corresponding to the maximum search count according to the search order in "EkiSpert". After this, the system uses the value of sort classification to extract the routes with maximum answer count. In other words, the accuracy of "cheap" and "easy" improves by increasing the maximum search count and the maximum answer count. When there are too many returned routes, specify searchCount=20, and then assign the number of routes you want for the maximum answer count and the sort classification you want to prioritize.

searchCount=20&answerCount=5&sort=price

In the above example of parameter specification, 20 routes are acquired in the search order of "station station", and the top five items sorted by price are returned.

sort by typedoes not allow to set more than one value at a time, so if you want to give priority to both "cheap" and "easy", we recommend following the procedure of point 1.

2. Determine "fast" route

route search by average wait timein this case, and route search by operation diagramin this case, the determination material will differ.

In case of searching by average wait time

It is a method to make things with the shortest time totaling the ride, move, waiting time etc. as the "early" route.

The comparison target is the following three values.

The total value of the three values is compared with that of each route, and the route with the smallest value is the "quick" route.

In case of search by schedule

For searches made with specified departure time, the one with the earliest arrival time, while for searches made with specified arrival time, the one with the latest departure time, will be chosen as the "fast" route.

When searching by specifying departure time

search typetargets departure time search and first train search.

1. 14:17発 ~ 14:23着 (「早」経路)
2. 14:15発 ~ 14:23着
3. 14:17発 ~ 14:25着
  1. Sorts in the order of sooner to later arrival times (last section of the route ResultSet/Course/Route/Line/ArrivalState/Datetime value).
  2. If the arrival time is the same, it sorts in the order of later to sooner departure times (first section of the routeResultSet/Course/Route/Line/DepartureState/Datetime value).
In case of arrival time search and last train search

search typetargets arrival time search and final train search.

1. 13:06発 ~ 14:02着 (「早」経路)
2. 13:04発 ~ 13:50着
3. 12:59発 ~ 14:00着
  1. Sorts in the order of later to sooner departure times (first section of the routeResultSet/Course/Route/Line/DepartureState/Datetime value).
  2. If the departure time is the same, it sorts in the order of sooner to later arrival times (last section of the routeResultSet/Course/Route/Line/ArrivalState/Datetime value).

The first route of the sorted result is the "quick" route.

3. Determine "cheap" route

Targets of comparison depend on whether you are comparing ene-way shipping rates, round trip shipping rates, or fixed-term commutation pass rates.

:
<Price kind="FareSummary">
<Oneway>310</Oneway>
<Round>620</Round>
</Price>
<Price kind="Teiki1Summary">
<Oneway>10520</Oneway>
</Price>
<Price kind="Teiki3Summary">
<Oneway>29990</Oneway>
</Price>
<Price kind="Teiki6Summary">
<Oneway>54480</Oneway>
</Price>
:

When comparing by one way fare

Target for comparison isResultSet/Course/Price/kind's value, when it is the FareSummaryResultSet/Course/Price/Oneway value.

When comparing by round trip fare

Target for comparison isResultSet/Course/Price/kind's value, when it is the FareSummaryResultSet/Course/Price/Round value.

When comparing by commuter pass charge

For targets of comparison, the value of ResultSet/Course/Price/kind is Teiki1Summary, Teiki3Summary or Teiki6Summary, which is the value of ResultSet/Course/Price/Oneway.

Compared with each route, the route with the lowest value is the "cheap" route.

4. Determine "easy" route

If "comfort" is defined as having the least transfers, ResultSet/Course/Route/transferCount is used for comparison.

After comparing each route, the route with the lowest cost will be the "comfort" route.

ページ上部へ