Completing the web service.

[Konstantin Schubert]

Hi,

I am thinking of completing the web service part of the project. But first, I have some questions:

1. Is there support for this endavour? I mean, if I make PR's that improve the web service, would anyone be interested in reviewing them?

2. Why is this line here https://github.com/schildbach/public-transport-enabler/blob/master/service/src/main/java/de/schildbach/pte/service/LocationController.java#L40 just setting RtProvider as the provider? That's just one provider our of many, right? Should the API let the user specify the provider he wants to use? It could be part of the REST path.

3. Bonues question: Have there been any attempts in the past to unify the providers?

[Konstantin Schubert]

Replying to myself because I had forgotten to activate Email updates.

[Andreas Schildbach]

On 10/05/2017 12:58 AM, Konstantin Schubert wrote:

> I am thinking of completing the web service part of the project. But
> first, I have some questions:
>
> 1. Is there support for this endavour? I mean, if I make PR's that
> improve the web service, would anyone be interested in reviewing them?

I personally don't see much "market" for it. But let's see what others say.

> 2. Why is this line here
> https://github.com/schildbach/public-transport-enabler/blob/master/service/src/main/java/de/schildbach/pte/service/LocationController.java#L40
> just setting RtProvider as the provider? That's just one provider our of
> many, right? Should the API let the user specify the provider he wants
> to use? It could be part of the REST path.

I guess it's caused by a mixture of incomplete implementation and
laziness. Yes, I agree at the end of the day there should be a way to
choose the provider.

> 3. Bonues question: Have there been any attempts in the past to unify
> the providers?

How do you mean? Lots of code is already unified in the abstract base
classes, e.g. AbstractEfaProvider.

[Konstantin Schubert]

On Thursday, October 5, 2017 at 3:44:36 PM UTC+2, Andreas Schildbach wrote:

On 10/05/2017 12:58 AM, Konstantin Schubert wrote:

> I am thinking of completing the web service part of the project. But
> first, I have some questions:
>
> 1. Is there support for this endavour? I mean, if I make PR's that
> improve the web service, would anyone be interested in reviewing them?

I personally don't see much "market" for it. But let's see what others say.

I think the market for a puiblic transport API with actually good coverage in Germany would be quite big. no? I stumbled upon this project becuase I want to build a public transport app, but no API comes close to Offis data source. And since the project will be written in python, I cannot use the library directly. So I will need an API.

 

> 2. Why is this line here
> https://github.com/schildbach/public-transport-enabler/blob/master/service/src/main/java/de/schildbach/pte/service/LocationController.java#L40
> just setting RtProvider as the provider? That's just one provider our of
> many, right? Should the API let the user specify the provider he wants
> to use? It could be part of the REST path.

I guess it's caused by a mixture of incomplete implementation and
laziness. Yes, I agree at the end of the day there should be a way to
choose the provider.

> 3. Bonues question: Have there been any attempts in the past to unify
> the providers?

How do you mean? Lots of code is already unified in the abstract base
classes, e.g. AbstractEfaProvider.

No, I mean in terms of not requiring the user to choose a provider. You enter two stations and the library selects the right provider for this combination of stations. Or, even more ambitous, to try to convert at the API  data into gtfs realtime data and feed it into a single routing algorithm.

I am aware that this probably isn't possible for performance reasons and so on, I am just wondering if it has been tried before.

[Andreas Schildbach]

On 10/05/2017 06:17 PM, Konstantin Schubert wrote:

> > 1. Is there support for this endavour? I mean, if I make PR's that
> > improve the web service, would anyone be interested in reviewing
> them?
>
> I personally don't see much "market" for it. But let's see what
> others say.
>
> I think the market for a puiblic transport API with actually good
> coverage in Germany would be quite big. no? I stumbled upon this project
> becuase I want to build a public transport app, but no API comes close
> to Offis data source. And since the project will be written in python, I
> cannot use the library directly. So I will need an API.

Ok, so you are just starting to create a market (-: Now ask yourself:
if you set up a service for your app, would you allow others to access
your service too?

> How do you mean? Lots of code is already unified in the abstract base
> classes, e.g. AbstractEfaProvider.
>
>

> No, I mean in terms of *not *requiring the user to choose a provider.

> You enter two stations and the library selects the right provider for
> this combination of stations. Or, even more ambitous, to try to convert
> at the API  data into gtfs realtime data and feed it into a single
> routing algorithm.

I'm not sure if it has been tried, but I reckon it's very difficult.
Different providers use different names and IDs for the same station.
Imho the unification would need to happen at the providers themselves.
And actually it is happening. For example, BahnProvider covers pretty
much entire Europe these days, in many cases down to bus level.

[Konstantin Schubert]

On Fri, Oct 6, 2017 at 6:47 PM Andreas Schildbach <and...@schildbach.de> wrote:

On 10/05/2017 06:17 PM, Konstantin Schubert wrote:

>     > 1. Is there support for this endavour? I mean, if I make PR's that
>     > improve the web service, would anyone be interested in reviewing
>     them?
>
>     I personally don't see much "market" for it. But let's see what
>     others say.
>
> I think the market for a puiblic transport API with actually good
> coverage in Germany would be quite big. no? I stumbled upon this project
> becuase I want to build a public transport app, but no API comes close
> to Offis data source. And since the project will be written in python, I
> cannot use the library directly. So I will need an API.

Ok, so you are just starting to create a market (-:  Now ask yourself:
if you set up a service for your app, would you allow others to access
your service too?

Well, the code for the service would be part of public-transport-enabler, so it would be open source and everybody could run it. To be completely honest, I would probably try take some money for using MY instance of the API.

Honestly, after reading through the code a little, it does not seem too hard to complete the `service` code into a REST API. And considering that you have been answering my emails very consistently, I am now confident that you will at least take the time to explain me why you don't like my PR :D

>     How do you mean? Lots of code is already unified in the abstract base
>     classes, e.g. AbstractEfaProvider.
>
>
> No, I mean in terms of *not *requiring the user to choose a provider.
> You enter two stations and the library selects the right provider for
> this combination of stations. Or, even more ambitous, to try to convert
> at the API  data into gtfs realtime data and feed it into a single
> routing algorithm.

I'm not sure if it has been tried, but I reckon it's very difficult.
Different providers use different names and IDs for the same station.

 

Maybe we could somehow figure out the coordinates of the stations and match them this way?

I think an even bigger problem would be to route between providers. So yes, it's difficult.

Imho the unification would need to happen at the providers themselves.
And actually it is happening. For example, BahnProvider covers pretty
much entire Europe these days, in many cases down to bus level.

I am glad to hear that this is happening. But as long as the users of oeffi have to choose a network when starting the app, I do not consider the problem as solved :)

 

--
You received this message because you are subscribed to a topic in the Google Groups "public-transport-enabler-discuss" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/public-transport-enabler-discuss/_fuDEcweP1Y/unsubscribe.
To unsubscribe from this group and all its topics, send an email to public-transport-enabl...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Merz]

And did you complete your project until now or did you open source some of your code?

To unsubscribe from this group and all its topics, send an email to public-transport-enabler-discuss+unsubscribe@googlegroups.com.