Map for all routes in Vienna puts one waypoint in Atlantic Ocean

[hgvhgv]

On Android 7.0 / Nexus 5x, the maps for all routes generated in Vienna put one waypoint (transfer/endpoint) in the Atlantic Ocean (south of Accra and west of Libreville). The point is labeled as one of the actual points on the route, and when you do zoom in to Vienna, the route is correct but doesn't include the legs surrounding the errant waypoint.

It's a minor annoyance to have to zoom in every time I look at the map from so far out, but overall it is not a major bug. It seems to happen on all routes in Vienna but I haven't been systematic about my testing.

See attached screenshots for more. They show, in order: 1) the route; 2) the first screen shown after clicking the map button for a route, auto-zoomed out to include the errant waypoint; 3) the info about the errant point; 4) the full actual route on the map of Vienna; 5) the route zoomed to the missing section around the point (here "Simmering S+U") that is missing/in the Atlantic.

[grote]

Thanks for the report. I'm afraid this is either a problem with the Wiener Linien API directly or the public-transport-enabler library that Transportr uses. So there's nothing really that Transportr can do about it.

[grote]

The code for Wien seems to use the normal Efa Provider code without real modifications, so my bet is that their API is at fault. You could try reproducing the problem with http://www.wienerlinien.at/

[hgvhgv]

Thx! I'll do my best to track this down and report it upstream appropriately. Great app!

[schildbach]

I guess you mean the API at https://www.wienerlinien.at/ogd_routing/ ? Can you provide an URL that queries the API for the data that exhibits the problem? Maybe @grote can help.

Generally I'm not surprised that the WL API is broken. They have build the API as a reaction to public pressure to provide open data, but they don't use the API themselves and now that nobody cares any more about open data the WL do not care about their API too.

[hgvhgv]

Hmm, yes, that's the only API for WL I can find in either repo, but I'm a rank amateur. In terms of where the API query in Transportr is coming from, I can only guess (https://github.com/grote/Transportr/blob/master/src/de/grobox/liberario/activities/MainActivity.java or https://github.com/grote/Transportr/blob/master/src/de/grobox/liberario/activities/TripsActivity.java)

If WL doesn't seem committed to keeping the API running well, then there's not much point in trying to track this down (seems to me). Thanks for looking in to it.

[grote]

Making some queries, I could not reproduce the missing coordinates anymore. Did they maybe fix that?

But I saw an exception which also contains the query string:

10-23 12:44:57.494 W/System.err: de.schildbach.pte.exception.InternalErrorException: https://www.wienerlinien.at/ogd_routing/XSLT_TRIP_REQUEST2?outputFormat=XML&language=de&stateless=1&coordOutputFormat=WGS84&sessionID=0&requestID=0&coordListOutputFormat=STRING&type_origin=coord&name_origin=16.363909:48.225522:WGS84&type_destination=poi&name_destination=poiID%3A1663%3A49000000%3A-1&itdDate=20161023&itdTime=1644&itdTripDateTimeDepArr=dep&calcNumberOfTrips=6&ptOptionsActive=1&itOptionsActive=1&routeType=LEASTTIME&changeSpeed=normal&includedMeans=checkbox&inclMOT_0=on&inclMOT_0=on&inclMOT_1=on&inclMOT_2=on&inclMOT_3=on&inclMOT_4=on&inclMOT_5=on&inclMOT_6=on&inclMOT_7=on&inclMOT_9=on&inclMOT_8=on&inclMOT_10=on&useProxFootSearch=1&trITMOTvalue100=10&locationServerActive=1&useRealtime=1&nextDepsPerLeg=1&inclMOT_11=on
10-23 12:44:57.499 W/System.err:     at de.schildbach.pte.util.HttpClient.getInputStream(HttpClient.java:222)
10-23 12:44:57.499 W/System.err:     at de.schildbach.pte.util.HttpClient.getInputStream(HttpClient.java:148)
10-23 12:44:57.499 W/System.err:     at de.schildbach.pte.AbstractEfaProvider.queryTrips(AbstractEfaProvider.java:2074)

[grote]

@schildbach Since you switched to okhttp, I don't see the queries in the log anymore. Do you know the magic I need to do to reenable them?

@hgvhgv

If WL doesn't seem committed to keeping the API running well, then there's not much point in trying to track this down (seems to me)

Well, you could still ask them about that and thus increase public pressure again, show them that there's people using this API and that they maybe should start maintaining it better.

[schildbach]

@grote In HttpClient.java you'll find

        final HttpLoggingInterceptor loggingInterceptor = new HttpLoggingInterceptor(
                new HttpLoggingInterceptor.Logger() {
                    @Override
                    public void log(final String message) {
                        log.debug(message);
                    }
                });
        loggingInterceptor.setLevel(HttpLoggingInterceptor.Level.BASIC);

You should see basic info (just the URLs) logged at debug. I'd try switching debug to info.