Implementing Provider#getArea()

[Torsten Grote]

Hi all,

it seems that most providers do not implement getArea(). The Navitia
providers do implement it, but do a blocking network call to retrieve
the area (with maaany points).

My goal is that all providers return a meaningful result for getArea()
without resorting to query a network service. The area a provider covers
should be more or less static, so that should be possible.

How about a PR (or a serious of PRs) that implements getArea() for all
providers where the list of points returned by this method is static,
not too long and defines a polygon that roughly covers the main area
served by the provider?

So for the DbProvider for example, getArea() would return a rough
polygon that covers Germany even though the provider can also return
results outside of Germany.

Maybe there should also be a second getExtendedArea() method that would
include the whole of Europe for the DbProvider?

What do you think?

Kind Regards,
Torsten

[Andreas Schildbach]

I agree it would be nice if that call would be implemented by more
providers. A couple of years ago when I introduced this call, I thought
it would be easier to get this data from the authorities. Turns out,
they don't know their coverage/authority exactly themselves.

That "extended area" idea is even more difficult, because actual API
coverage is very fluid, both in time and in space. Yes DbProvider covers
whole Europe, but the more you get away from Germany the less dense its
coverage gets.

I'm not opposed to sychronous queries to the network, since that's what
almost all the NetworkProvider calls do. However I'm thinking about
providing asynchronous alternatives, now that we have switched to OkHttp
which supports async IO very well. From the Öffi perspective,
getDepartures() would be a good first call to explore into this. Öffi
Stations uses getDepartures() quite a lot and running multiple queries
in parallel (over the same HTTP connection) would be nice to have.