Correct values for NTA API

17 views

Skip to first unread message

Kenny Chapman

unread,

Feb 24, 2012, 3:39:56 PM2/24/12

to sept...@googlegroups.com

Hey, what are the correct values for the 49th St and Chester TC stations

I've tried

http://www3.septa.org/hackathon/NextToArrive/Suburban%20Station/49th%20St/10

and

http://www3.septa.org/hackathon/NextToArrive/Suburban%20Station/Chester%20TC/10

Kenny Chapman

unread,

Feb 24, 2012, 3:47:43 PM2/24/12

to sept...@googlegroups.com

I'm also having trouble with Ste Martins and Ste Davids

Daniel Watson

unread,

Feb 24, 2012, 4:00:06 PM2/24/12

to sept...@googlegroups.com

I think it would make a lot more sense if these APIs stuck to the GTFS route_id's stop_id's etc. I'm implementing alerts at the moment and it would be much nicer to be able to cross reference the route_id instead of the (many differences) in string names.

Brian Ferris

unread,

Feb 27, 2012, 3:42:46 AM2/27/12

to sept...@googlegroups.com

+1 to using GTFS stop and route ids. I ran into the same problem when working with the APIs.

Kenny Chapman

unread,

Feb 27, 2012, 11:52:56 AM2/27/12

to sept...@googlegroups.com

I used the route_name in the alerts, they pretty much match up. From what I've read, your developing an app on android also. What I did was when the app starts I start a service/content provider to get the alerts and put them in a database. Then when someone views a schedule I check the database to see if there is an alert matching the route_name. Then I get the single alert using the route_id

Daniel Watson

unread,

Feb 27, 2012, 12:07:52 PM2/27/12

to sept...@googlegroups.com

Hi Kenny. Yes, I'm developing an android application as a side project, and I bet a lot of the way we are processing and displaying things is very similar. for instance, I just noticed you updated your app to include push notifications (my notifications have been in development for several weeks now) - funnily enough, i'm using the exact same procedure to store and retrieve the JSON alerts as the local cache is also necessary in my case.

Regarding the route name id's, a lot of the route names are similar that can be parsed easily (i.e: trolley_13), but there are also a lot of string names that don't really make sense (' rr_route_gc '?) when relating to the GTFS data. The primary keys in the GTFS data are good enough, and we have them for free.

Daniel

Kenny Chapman

unread,

Feb 27, 2012, 12:48:02 PM2/27/12

to sept...@googlegroups.com

For the route_id trolley_13, the route_name in the json response is "13" so there is no parsing needed in that case. For rr_route_gc the route_name is "Glenside Conbined, you right about that since there is no Glenside Combined route, at least according to the GTFS

Mike Z

unread,

Feb 27, 2012, 2:25:06 PM2/27/12

to SEPTAdev

We're aware of the naming convention discrepancies as well as the need
for documentation; we'll work on both as time allows.

Glenside Combined is just a 'view' of the RR schedules, it aggregates
the schedules and shows all the trains that operate between University
City and Glenside, the so-called 'trunk' of the railroad. Since most
trains pass thru the trunk, the combined schedule is provided as a
convenience to those people who prefer their schedules served with out
all the extra outlying-points info.

On Feb 27, 12:48 pm, Kenny Chapman <lkchap...@gmail.com> wrote:
> For the route_id trolley_13, the route_name in the json response is "13" so
> there is no parsing needed in that case. For rr_route_gc the route_name is
> "Glenside Conbined, you right about that since there is no Glenside
> Combined route, at least according to the GTFS
>
>
>
>
>
>
>
> On Monday, February 27, 2012 12:07:52 PM UTC-5, Daniel wrote:
>
> > Hi Kenny. Yes, I'm developing an android application as a side project,
> > and I bet a lot of the way we are processing and displaying things is very
> > similar. for instance, I just noticed you updated your app to include push
> > notifications (my notifications have been in development for several weeks
> > now) - funnily enough, i'm using the exact same procedure to store
> > and retrieve the JSON alerts as the local cache is also necessary in my
> > case.
>
> > Regarding the route name id's, a lot of the route names are similar that
> > can be parsed easily (i.e: trolley_13), but there are also a lot of string
> > names that don't really make sense (' rr_route_gc '?) when relating to
> > the GTFS data. The primary keys in the GTFS data are good enough, and we
> > have them for free.
>
> > Daniel
>

> > On 27 February 2012 11:52, Kenny Chapman <lkchap...@gmail.com> wrote:
>
> >> I used the route_name in the alerts, they pretty much match up. From what
> >> I've read, your developing an app on android also. What I did was when the
> >> app starts I start a service/content provider to get the alerts and put
> >> them in a database. Then when someone views a schedule I check the database
> >> to see if there is an alert matching the route_name. Then I get the single
> >> alert using the route_id
>
> >> On Friday, February 24, 2012 4:00:06 PM UTC-5, Daniel wrote:
>
> >>> I think it would make a lot more sense if these APIs stuck to the GTFS
> >>> route_id's stop_id's etc. I'm implementing alerts at the moment and it
> >>> would be much nicer to be able to cross reference the route_id instead of
> >>> the (many differences) in string names.
>

> >>> On 24 February 2012 15:47, Kenny Chapman <lkchap...@gmail.com> wrote:
>
> >>>> I'm also having trouble with Ste Martins and Ste Davids
>
> >>>> On Friday, February 24, 2012 3:39:56 PM UTC-5, Kenny Chapman wrote:
>
> >>>>> Hey, what are the correct values for the 49th St and Chester TC
> >>>>> stations
> >>>>> I've tried

> >>>>>http://www3.septa.org/**hackatho**n/NextToArrive/**Suburban%**
> >>>>> 20Station/49th%20St/**10<http://www3.septa.org/hackathon/NextToArrive/Suburban%20Station/49th%...>
>
> >>>>> and
> >>>>>http://www3.septa.org/**hackatho**n/NextToArrive/**Suburban%**
> >>>>> 20Station/Chester%**20TC/10<http://www3.septa.org/hackathon/NextToArrive/Suburban%20Station/Chest...>

>
> >> On Friday, February 24, 2012 4:00:06 PM UTC-5, Daniel wrote:
>
> >>> I think it would make a lot more sense if these APIs stuck to the GTFS
> >>> route_id's stop_id's etc. I'm implementing alerts at the moment and it
> >>> would be much nicer to be able to cross reference the route_id instead of
> >>> the (many differences) in string names.
>

>
> On Monday, February 27, 2012 12:07:52 PM UTC-5, Daniel wrote:
>
> > Hi Kenny. Yes, I'm developing an android application as a side project,
> > and I bet a lot of the way we are processing and displaying things is very
> > similar. for instance, I just noticed you updated your app to include push
> > notifications (my notifications have been in development for several weeks
> > now) - funnily enough, i'm using the exact same procedure to store
> > and retrieve the JSON alerts as the local cache is also necessary in my
> > case.
>
> > Regarding the route name id's, a lot of the route names are similar that
> > can be parsed easily (i.e: trolley_13), but there are also a lot of string
> > names that don't really make sense (' rr_route_gc '?) when relating to
> > the GTFS data. The primary keys in the GTFS data are good enough, and we
> > have them for free.
>
> > Daniel
>

Reply all

Reply to author

Forward

0 new messages