Add more OTP endpoints and update coverage areas

[vkrause]

Coverage areas are no longer based on the (often bogus) bounding polygons
reported by the OTP instances themselves, but are now the convex hull of
all stops after applying basic outlier filtering on those.

[derhuerst]

Coverage areas [...] are now the convex hull of all stops after applying basic outlier filtering on those.

Including a buffer?

[vkrause]

Including a buffer?

Not at this point, and neither did OTP add one itself when computing the bounding boxes we used before IIUC.

Easy enough to add though, how much do we want?

More generally, we probably want better documentation on where we got the respective bounding polygons from and what kind of post-processing has been applied, if any?

[derhuerst]

Easy enough to add though, how much do we want?

I'm not sure. I'd say big enough to include positions in comfortable walking distance (e.g. 500m), or at least positions within common GPS uncertainties (e.g. 30m).

On the other hand, an application using this polygon in its business logic can decide much better what buffer to apply; I'd say this boils down to user friendliness vs access to raw data. What do you think?

More generally, we probably want better documentation on where we got the respective bounding polygons from and what kind of post-processing has been applied, if any?

Yes, definitely. Maybe we can add a "comment field".

[vkrause]

Easy enough to add though, how much do we want?

I'm not sure. I'd say big enough to include positions in comfortable walking distance (e.g. 500m), or at least positions within common GPS uncertainties (e.g. 30m).

Right. This is probably particularly relevant for those endpoints where the bounding polygon is actually tightly fitted around the covered area (like the ones in the US). The local German ones however tend to be considerably larger than the area they cover properly, due to longer-distance lines leading into their area. For those we'd actually need a better way to trim the bounding area.

On the other hand, an application using this polygon in its business logic can decide much better what buffer to apply; I'd say this boils down to user friendliness vs access to raw data. What do you think?

Right, we do our own processing of the polygons in KPublicTransport, so for that it wouldn't matter either way. Hard to judge what properties would be desired for simpler use-cases.

More generally, we probably want better documentation on where we got the respective bounding polygons from and what kind of post-processing has been applied, if any?

Yes, definitely. Maybe we can add a "comment field".

That's one option, a markdown file with the same name alongside the JSON files might be another, especially if this grows further. Besides the bounding polygons there's probably more details worth documenting, like where to get API keys from (e.g. for TRIAS/OJP/Navitia endpoints), or things we can't model properly in the JSON files yet, like supported Hafas mode groups (see e.g. public-transport/hafas-client#218).

[derhuerst]

Shall we merge this?

Reading this again, I agree that specifying a buffer around the convex hull of serviced stops – or even specifying the serviced area – is not so trivial and out of scope of this PR.

[vkrause]

I'd say so, yes. There definitely is still work to be done to clarify how we specify the coverage area, both for the bounding geometry and for the region, but I think that is indeed a separate (and bigger) task.