This makes the lat/lon member variables private and adds 1E6 variants for getters and the static constructor.
Also, Location now stores a Point for its coordinate, rather than 1E6 ints. The 1E6-based constructors have been removed.
The navitia developers have informed me that the "quality" of
auto-completion results is deprecated and already meaningless.
Also, we had a wrong inverse sorting order before. The only thing that
matters is the sort order in which the results are returned.
This commit fixes the sort order accordingly.
This commit adds the house number behind the street name if available
and gives a way to define other formats like in France
where the house number comes before the street name.
This allows coverages with multiple distinct transport agencies
(e.g. Australia) to meaninfully distinguish between different lines
with similar names. For example, there is often buses which are
labelled by numbers. "Bus 12" needs to be two different colours,
based on which transport network it belongs to.
In the case of Australia, it will use this to delegate to the
lineStyles() method.
Use the `min_nb_journeys` parameter rather than the `count` parameter
when requesting trips.
The `count` parameter causes Navitia to remove trips arbitrarily
from the result which can look like a bug to the user
when she knows a trip should be there, but it isn't.
4f7bd832e6 introduced a
NullPointerException in AbstractNavitiaProvider.
The call to Context() in line 970 calls prevQueryUrl.toString() and
nextQueryUrl.toString().
The variables are however null in the case that the search returned
only one result. The easiest way to reproduce this is searching
for two very near locations. The result will then be one walk-route.
This commit fixes the NPE by restoring the old behavior and has been
tested in Transportr.
Notes regarding Android compatibility:
- The 'try-with-resources' language feature needs API level 19, so don't use it.
All other language features can be used back to API level 8.
- The JDK 1.7 API still isn't fully implemented, so better stick with 1.6 for now.
According to CanalTP/navitia#1386, Navitia has finally added the
product to departure query results, so all information we need can now
be retrieved by one network query only.
The AbstractNavitiaProvider was adapted accordingly and all legacy code
including the Product Cache was removed.
Also add network to Navitia providers and take text color into account.
Due to a bug uncovered by adding the network to the line,
the code to retrieve departures had to be simplified.
It now does not do an extra network request to get the line destination.
The administrative areas are extremely useful when people search for a
suburb, but no stops have the suburbs name. They are currently mapped
to a POI location.
The AbstractNavitiaProvider was making one network request per departure
it found, just to find the `Product`. This information is mostly
available in the second request it makes, so this should be taken when
available.
Also, in rare cases no destination can be found for a line. It should
not crash in these cases. This was also fixed within this commit.
When querying departures from a stop_area with equiv=false
the query URI was wrong and returned no results.
This was especially problematic, because the suggestLocation query
returns only stop_areas at the moment.
