JSON-LD contexts for GTFS layers

bertspaan commented 9 years ago

The CitySDK LD API stores data per object, per layer. An object is something with a physical representation in a city (train station, bus stop, building, etc.), each object can have one or more layers with data.

We plan to define the following layers, based upon GTFS:

gtfs.stops - layer containing all GTFS stops, plus basic data (stop_id, stop_name, etc.)
gtfs.routes - layer containing all GTFS routes, plus basic data (route_id, agency_id, etc.)
gtfs.stops.routes - extra layer for each GTFS stop, containing routes calling at stop
gtfs.routes.stops - extra layer for each GTFS route, containing stops for route in right order
gtfs.stops.schedule - work-in-progress, layers 5 & 6 contain schedule data (probably for current day or week), for routes and stops
gtfs.routes.schedule
gtfs.stops.now - current departure times, per stop

When possible, we should use OpenTransport's vocabulary.

pietercolpaert commented 9 years ago

Great issue! Just a headstart of how it would look with the Linked GTFS vocabulary (http://vocab.gtfs.org)

For 1 - gtfs.stops:

Use these classes: gtfs:Stop and gtfs:Station:

{
  "@context":
  {
    "gtfs" : "http://vocab.gtfs.org/terms#",
    "name": "http://xmlns.com/foaf/0.1/name",
    "code": "http://purl.org/dc/terms/identifier",
    "latitude" : "http://www.w3.org/2003/01/geo/wgs84_pos#lat",
    "longitude" : "http://www.w3.org/2003/01/geo/wgs84_pos#long",
    "description" : "http://purl.org/dc/terms/description",
    "zone": { → you might argue not to include this one as you will have to make this one dereferenceable as well
        "@id" : "gtfs:zone",
        "@type" : "@id"
     },
    "page" : {
        "@id" : "http://xmlns.com/foaf/0.1/page",
        "@type" : "@id"
     },
     "timezone" : "gtfs:timeZone",  
     "parentStation" : { → a link to a gtfs:Station
         "@id" : "gtfs:parentStation",
         "@type" : "@id"
     },
     "wheelchairaccessible" : {
         "@id" : "gtfs:wheelchairAccessible",
         "@type" : "@id" → one of these: gtfs:WheelchairAccessible or gtfs:NotWheelchairAccessible
     }
  }
}

For 2 - gtfs:routes

See gtfs:Route class and build json-ld context in the same way

For 3&4 - gtfs.stops.routes and gtfs.routes.stops

More explanation in your issue needed.

A gtfs:Route is a class which is used to give a commercial name to a number of trips which follow the same path. For instance "Tram 1". It maybe has a certain colour or a certain longer commercial name, etc, but it does not contain a fixed set of stops. For that, you will have to go over all trips that follow this route and check whether the stop is already included. This might indeed be valuable for certain use cases, but what you're doing is a data model transformation. In this transformed model, you will still be able to use a lot of terms from the linked gtfs vocabulary, but you will need 2 new predicates: 1 linking a route with a stop and 1 linking a stop with a route. These predicates would be interesting to be added to the open transport vocabulary (although, not in the GTFS one, as that one is just a translation of the CSV specification). Can you create an issue if that's indeed what you intended?

For 5, 6 and 7: scheduled stop times

The same comment: this is a big transformation of the data, but good news! We're working on exactly that use case as well! There are however no URIs defined yet. Have a look here:

https://github.com/OpenTransport/vocabulary#the-stop-times-vocabulary

bertspaan commented 9 years ago

@pietercolpaert Yes, it was a typo, it should be gtfs.routes. And I've added numbers to the last three layers.

pietercolpaert commented 9 years ago

Updated my comment :)

tomdemeyer commented 9 years ago

Thanks for your suggestions, your context is roughly what we had in mind, fills in more of the dots.. I think we should be clear that we use some of the GTFS terminology, but don't 'serve' GTFS. Point in case is indeed the routes. A CitySDK route is indeed the 'longest trip' to be found on a gtfs route. We should be quite clear that CitySDK should not be used for public transport trip planning..

pietercolpaert commented 9 years ago

@tomdemeyer I wouldn't say longest trip, I would say the union of the stops of all trips, and even then you're not 100% sure that you got all stops (e.g., a stop may be part of a route but currently out of service for a period longer than the gtfs timespan).

Not serving route planning is a good approach. It's impossible to serve that in a light-weight manner at this moment and there are already solutions for that out there :)

If you want to do get the latest departures in a certain stop or for a certain route/trip, there are 2 approaches you can follow:

Calculate the departures on each request
Precompute and store all the arrival/departures in a certain station as stoptimes (at iRail, we're currently going towards this direction: it's way cheaper to host)

pietercolpaert commented 9 years ago

Any update about this? :)

tomdemeyer commented 9 years ago

Hi Pieter

Yeah, sorry, wish I could spend more time on this…

As to your suggestions, yes, and 1st :) Yes to the union of all stops for all trips in a route. Least likely to have a mistake..

As to the departure times, we calculate them in postgres at the moment. Seems to perform good enough for now (not burdened by too many users, though, but we’re caching). I probably will not touch this for version 1.0

more later, t.

On 03 Nov 2014, at 16:47, Pieter Colpaert notifications@github.com wrote:

Any update about this? :)

— Reply to this email directly or view it on GitHub.

Tom Demeyer Waag Society http://waag.org

pietercolpaert commented 9 years ago

Alright! In the meantime, I have started working on an additional vocabulary to describe "stoptimes" (arrivals/departures). You can read about it here: https://github.com/OpenTransport/vocabulary/blob/master/stoptimes/spec.md. It uses the GTFS vocabulary heavily but extends it with a couple of URIs to be able to talk about departures and arrivals.

pietercolpaert commented 9 years ago

Today I'm in Amsterdam. If you want to have a beer/codesprint over this this evening, I'm all up for it :)

bertspaan commented 9 years ago

Pieter! Good plan! I have time until around 19:15. Or from around 21:30.

pietercolpaert commented 4 years ago

An update on this issue after 5 years (better late than never):

We now have proper mapping scripts here:

Instead of the StopTimes vocabulary we started developing the Linked Connections vocabulary, available at http://semweb.mmlab.be/ns/linkedconnections, and according mapping scripts and server at https://github.com/linkedconnections/linked-connections-server

This allows a route planner to start planning routes on the client-side. See our SDK at https://github.com/openplannerteam/planner.js

Related issue: NGSI-LD wants to do the same thing: https://github.com/FIWARE/dataModels/issues/536

bertspaan commented 4 years ago

Thanks for all the links!

waagsociety / citysdk-ld