OTP server v0.19 and higher broken REST API /metadata endpoint

[barbeau]

Looks like the OTP server v0.19.0 release changed the location of the /metadata endpoint: https://github.com/opentripplanner/OpenTripPlanner/commit/e32de4266a360f278ccc10320d4df13aa5ee2e52

It used to be this: https://mobullity.forest.usf.edu/otp/routers/default/metadata

Response:

<GraphMetadata>
<lowerLeftLatitude>27.279000000000003</lowerLeftLatitude>
<lowerLeftLongitude>-82.8511308</lowerLeftLongitude>
<upperRightLatitude>28.3759997</upperRightLatitude>
<upperRightLongitude>-82.01201400000001</upperRightLongitude>
<transitModes>
<transitModes>TRAM</transitModes>
<transitModes>BUS</transitModes>
</transitModes>
<centerLatitude>27.827499850000002</centerLatitude>
<centerLongitude>-82.43157240000001</centerLongitude>
<minLatitude>27.279000000000003</minLatitude>
<minLongitude>-82.8511308</minLongitude>
<maxLatitude>28.3759997</maxLatitude>
<maxLongitude>-82.01201400000001</maxLongitude>
</GraphMetadata>

There isn't a /metadata endpoint in v1.0, but the /routers/default/ seems to return the same info.

Request: http://api.mfdz.de/otp/routers/default

Response:

<RouterInfo>
<routerId>default</routerId>
<polygon>
<type>Polygon</type>
<coordinates>9.8318005</coordinates>
<coordinates>47.6874999</coordinates>
<coordinates>8.8390449999999</coordinates>
<coordinates>47.758437</coordinates>
<coordinates>8.1907891</coordinates>
<coordinates>47.9429619</coordinates>
<coordinates>6.9969327</coordinates>
<coordinates>49.2401572</coordinates>
<coordinates>8.0066862</coordinates>
<coordinates>50.2588824</coordinates>
<coordinates>12.2424516</coordinates>
<coordinates>51.8222436</coordinates>
<coordinates>14.968707</coordinates>
<coordinates>51.1506269</coordinates>
<coordinates>12.1565803</coordinates>
<coordinates>47.7428876</coordinates>
<coordinates>9.8318005</coordinates>
<coordinates>47.6874999</coordinates>
</polygon>
<buildTime>1479017424331</buildTime>
<transitServiceStarts>-3600</transitServiceStarts>
<transitServiceEnds>1481842800</transitServiceEnds>
<transitModes>
<transitModes>FUNICULAR</transitModes>
<transitModes>RIDESHARING</transitModes>
<transitModes>SUBWAY</transitModes>
<transitModes>BUS</transitModes>
<transitModes>RAIL</transitModes>
</transitModes>
<centerLatitude>48.7877625745312</centerLatitude>
<centerLongitude>9.20791407138682</centerLongitude>
<hasParkRide>true</hasParkRide>
<travelOptions>
<travelOptions>
<value>TRANSIT,WALK</value>
<name>TRANSIT</name>
</travelOptions>
<travelOptions>
<value>FUNICULAR,WALK</value>
<name>FUNICULAR</name>
</travelOptions>
<travelOptions>
<value>RIDESHARING,WALK</value>
<name>RIDESHARING</name>
</travelOptions>
<travelOptions>
<value>SUBWAY,WALK</value>
<name>SUBWAY</name>
</travelOptions>
<travelOptions>
<value>BUS,WALK</value>
<name>BUS</name>
</travelOptions>
<travelOptions>
<value>RAIL,WALK</value>
<name>RAIL</name>
</travelOptions>
<travelOptions>
<value>WALK</value>
<name>WALK</name>
</travelOptions>
<travelOptions>
<value>BICYCLE</value>
<name>BICYCLE</name>
</travelOptions>
<travelOptions>
<value>CAR</value>
<name>CAR</name>
</travelOptions>
<travelOptions>
<value>TRANSIT,BICYCLE</value>
<name>TRANSIT_BICYCLE</name>
</travelOptions>
<travelOptions>
<value>CAR_PARK,WALK,TRANSIT</value>
<name>PARKRIDE</name>
</travelOptions>
<travelOptions>
<value>CAR,WALK,TRANSIT</value>
<name>KISSRIDE</name>
</travelOptions>
</travelOptions>
<lowerLeftLongitude>6.9969327</lowerLeftLongitude>
<lowerLeftLatitude>47.6874999</lowerLeftLatitude>
<upperRightLongitude>14.968707</upperRightLongitude>
<upperRightLatitude>51.8222436</upperRightLatitude>
<hasBikeSharing>false</hasBikeSharing>
<hasBikePark>false</hasBikePark>
</RouterInfo>

I guess we should change to trying the root first (assuming most people going forward will be using v1.0 or later), and then fall back to /metadata if the root fails.

We could also hit the main /otp endpoint and get the server version there: http://api.mfdz.de/otp/

Response:

<ServerInfo>
<serverVersion>
<version>1.1.0-SNAPSHOT</version>
<major>1</major>
<minor>1</minor>
<incremental>0</incremental>
<qualifier>SNAPSHOT</qualifier>
<commit>${git.commit.id}</commit>
<describe>${git.commit.id.describe}</describe>
<commit_time>${git.commit.time}</commit_time>
<build_time>${git.build.time}</build_time>
<longVersionString>
version: 1.1.0-SNAPSHOT major: 1 minor: 1 patch: 0 qualifier: SNAPSHOT commit: ${git.commit.id}
</longVersionString>
<shortVersionString>OpenTripPlanner 1.1.0-SNAPSHOT ${git.commit.id}</shortVersionString>
<uid>-1001000</uid>
</serverVersion>
<cpuName>Intel(R) Xeon(R) CPU E3-1270 v3 @ 3.50GHz</cpuName>
<nCores>8</nCores>
</ServerInfo>

[hbruch]

Currently, the server version is already requested in the ServerChecker. Depending on the version, the api version parameter is stored in the preferences, which would be natural to reuse. As the API version seems to be a concept introduced by otp-for-android and not an official otp value, it could be incremented to reflect this (and perhaps further?) changes in OTP v1.0.

However, current uses of the OTPApp.PREFERENCE_KEY_API_VERSION explicitly compare to version 1 and would need to be adapted, if a new version should be introduced.

Think this would be the best option compared to doing trial and error requests for multiple urls, accessing the server info here again or introducing a new preference value for the server version.

[hbruch]

The metadata endpoint was removed in otp with commit ac1f29c ("Removed GraphMetadata API point", 2015-06-05), so any otp server version equal to or greater than 0.19 will suffer from this issue.

[barbeau]

@hbruch Thanks! You're correct, looks like this affects 0.19 and above.

[barbeau]

Also, I believe this only affects when a server is entered as a custom API - I believe we use the bounds from the OTP Server Directory for those servers.