Till senaste kommentaren

GTFS Regional Static data (beta) - turnummer

Hej,

I filen trips.txt med exempel:

route_id,service_id,trip_id,trip_headsign,direction_id,shape_id
9011006051000000,1,141010000967599105,,1,1

så vet jag inte hur jag skall tolka trip_id?

Jag har sett exempel i andra integrationer mot Pibtrans där man med en GID beskriver en linje/tur med 9015123123412345 där de sista 5 är turnr.

Jag är ute efter det turnr som gäller för turen på linjen.

Kommentarer

  • Hej,

    Du borde inte tolka id:er. Just nu matchar de med interna system av några operator, men det finns ingen garanti alls att de alltid ska matchas. Id:er är bara där för att länka GTFS filer tillsammans.

    Det finns extra filer för GTFS Regional (som de finns för GTFS Sverige 2), som kan hjälpa de som vill integrera med operatörernas systemer. Du kan hitta de genom att ersätta arkivnamnet med samma namn + "_extra". Till exempel https://opendata.samtrafiken.se/otraf/otraf_extra.zip . Just nu innehåller den bara en mappning mellan trip_id och källans dated_vehicle_id.

    Jag återkommer med information kring hur du kan får ut det tekniska turnumret för turen på linjen.

    Hälsningar,
    Bert

    Bert på Trafiklab
  • Hej,

    Så jag kan inte tolka route_id 9011006051000000 som att ha det tekniska linje numret 0510 (510) ?
    Daniel
  • Hej,

    Enligt Noptis stämmer det att det är tekniska linjenumret, och i denna fall har vi återanvänd en Noptis ID som GTFS id, men det funkar inte alltid så.

    I framtiden kan vi ändra på våra id:er utan att ge en varning eftersom det är "bara" en id, som inte har speciell betydelse i GTFS. Det ska inte funka för operatörerna som levererar data i en annan format än Noptis, så du kan inte bygga en lösning som ska funka "för alla" på denna sätt. En exempel är SJ, Tågab, Västmaneland, ... som leverer data i andra format. Om ni har behov av det här kan vi troligen lägga till en ny extra fil just som vi har det i GTFS Sverige 2. Då har ni ett sätt att få ut ett teknisk linjenummer för alla operator, som inte ändras utan varning. Gärna ta kontakt genom mejl för att diskutera detta videra med utvecklingsteamet och projektledning.

    Hälsningar,
    Bert

    Bert på Trafiklab
  • Jag håller just nu på och implementerar detta gränssnittet och i princip all data jag behöver ligger just nu i dessa noptis GIDar som egentligen skall tolkas som refererbara IDs mellan filerna.

    Vi pratar om tekniskt linjenummer, hållplatsnummer, hållplatsställe, transporthuvudman mm och innan jag kan ha en lösning på plats så känns det som att jag kommer att behöva ha ett "antal" extrafiler på plats för att få ut den datan som ligger i GIDarna just nu.

    Hur troligt är det att ni kommer att frångå dessa noptis GIDar utan förvarning om man vill ha en lösning på plats snart och kan migrera senare (kräver ju att ni ger en heads-up och en migreringstid för det)?

    Daniel
  • Hej Daniel,
    Som Bert har förklarat så finns det inga garantier att id'n kommer att vara oförändrade. Så rekommendationen är att inte tolka dem.
    Exempelvis route_id kan sedan lång tid tillbaka vara på ett annorlunda format, beroende på hur indata ser ut. T.ex. för SL så hittar du route_id som ser ut så här: 9011001002800000-28X
    (Även där ser du förstås GIDen, men jag förmodar att du förstår min poäng).
    Ett annat exempel som troligen kommer ändras inom kort är att en del gid'ar i stops.txt och stop_times.txt kommer att komma från Journey Pattern Point snarare än Stop Point.
    Med det sagt så ändrar vi inte hipp-som-happ utan anledning, men vi kan inte heller låsa upp oss till att behöva förvarna och ge migreringstid för alla typer av ändringar, eftersom vi då inte kommer att kunna förvalta och vidarutveckla det öppna datat på ett effektivt sätt.

    Mvh Dick

    Samtrafiken

Kommentera eller skriv ett nytt inlägg

Ditt namn och inlägg kan ses av alla. Din e-post visas aldrig publikt.