Issues

  • GTFS Decode without .proto file

    How can I decode the GTFS response from the real-time API without having the .proto file ?

    Status: Proposed | Reported by Hidden Tue, 31 Mar 2020 07:38:39 GMT
  • Tijdzone real-timeTijdstip vs dienstregelingTijdstip

    "dienstregelingTijdstip" : "2020-03-29T11:36:00", "real-timeTijdstip" : "2020-03-29T10:37:23", dienstregelingTijdstip is een uur vooruit gegaan met het zomeruur, maar real-time tijdstip niet.

    Status: Proposed | Reported by Hidden Sun, 29 Mar 2020 09:31:16 GMT
  • Tijdzone real-timeTijdstip vs dienstregelingTijdstip

    "dienstregelingTijdstip" : "2020-03-29T11:36:00", "real-timeTijdstip" : "2020-03-29T10:37:23", dienstregelingTijdstip is een uur vooruit gegaan met het zomeruur, maar real-time tijdstip niet.

    Status: Proposed | Reported by Hidden Sun, 29 Mar 2020 09:31:15 GMT
  • Foutieve doorkomsten bij realtime endpoint

    Zaterdag 07/03/2020 viel me op dat de website van De Lijn weergeeft dat er geen doorkomsten zijn en dat er drie omleidingen actief zijn. https://www.delijn.be/nl/haltes/halte/305442/Leuven_J.Stasstraat Bij de real-time komen er geen omleidingen terug en worden er ook doorkomsten weergegeven, terwijl deze foutief zijn want in realiteit zijn de haltes afgeschaft. Hoe komt het dat deze foutieve gegevens worden aangeleverd? Op deze manier is het onmogelijk om deze gegevens te gebruiken, aangezien ze voor gebruikers foutief en verwarrend zijn... Response bij https://api.delijn.be/DLKernOpenData/api/v1/haltes/3/305442/real-time -> zie bijlage

    Status: Proposed | Reported by Hidden Sat, 07 Mar 2020 18:34:42 GMT
  • Lijnnummers met letters

    Bij het opvragen van realtime info (https://data.delijn.be/docs/services/KernOpenDataServicesV1/operations/geefDoorkomstenVoorHalte/console), bijvoorbeeld voor de halte 403235, komt er voor lijn H21 lijnnummer 521 terug. Ook via de andere API's, zoals lijnrichtingen (https://data.delijn.be/docs/services/KernOpenDataServicesV1/operations/geefLijnrichtingenLijst/console) komt er ook steeds 521 terug in plaats van H21. Het is niet mogelijk om er vanuit te gaan dat een 5 aan het begin van een lijnnummer gelijk is aan H, aangezien er in andere entiteiten wél lijnnummers zijn die met een 5 beginnen. Over het algemeen lijkt het me een best practise om overal de lijnnummers als een String terug te geven, in plaats van een Integer (gezien er nog vaak letters worden gebruikt in lijnnummers, zoals in Hasselt, Sint-Truiden…). Graag dit consistent doortrekken in alle API’s; bij voorkeur al zo snel mogelijk in de realtime-API. (In andere gevallen zou er steeds een extra API-call moeten gebeuren, puur om het lijnnummer correct te kunnen weergeven aan de eindgebruikers.)

    Status: Proposed | Reported by Hidden Sun, 01 Mar 2020 10:03:39 GMT
  • Koppel Realtime data met lijn

    Hoe kunnen GTFS Realtime API-gegevens worden gekoppeld aan een individuele lijn? Is er een logische verbinding met de FeedEntity ID (bijvoorbeeld 2020-01-09-1509-171-1015-0) of de TripDescriptor ID (voorbeeld 33420714). Alvast bedankt

    Status: Proposed | Reported by Hidden Thu, 09 Jan 2020 16:33:56 GMT
  • getRouteplan javascript ajax vervoersoptie parameter probleem

    Bij de API-methode geefRouteplan() kan normaal een array met vervoersOpties meegegeven worden. Volgens de voorziene code voor Javascript kan dit door een array toe te kennen aan "vervoersOptie" in de params-variabele. Deze code lijkt niet te werken. De bekomen url bevat bijvoorbeeld "vervoersOptie%5B%5D=BUS&vervoersOptie%5B%5D=TREIN". Met deze url lijkt de API-methode geen rekening te houden met deze parameters en geeft ze resultaten alsof een geen vervoersOptie meegegeven is. Dit probleem doet zich enkel voor wanneer een array meegeven wordt, niet bij 1 optie zoals bvb "BUS" Een weg hieromheen is het manueel aanvullen de url met bvb "vervoersOptie=BUS&vervoersOptie=TREIN".

    Status: Proposed | Reported by Hidden Wed, 25 Dec 2019 17:54:51 GMT
  • Timezone "Europe/Brussels" gebruikt in de datetime velden?

    Kwestie van de juiste code te schrijven, maar mag er vanuit gegaan worden dat de datetime in jullie responses in de timezone "Europe/Brussels" liggen? Bijvoorbeelde in de halteDoorkomsten keert er dit terug: "dienstregelingTijdstip": "2019-07-23T17:44:00", "real-timeTijdstip": "2019-07-23T17:42:14" Mijn vermoeden is dat het altijd de huidige Belgische tijd gebruikt, ongeacht of het winteruur of zomeruur is. Klopt dit? Kwestie dat ik de juiste interpretatie heb en dit kan gebruiken om het om te zetten naar een iets eneriekere UTC datetime voor mijn programma. Dank bij voorbaat.

    Status: Proposed | Reported by Hidden Wed, 24 Jul 2019 10:23:49 GMT
  • Realistisch voorbeeld voor geefStoringenVoorHalte

    Het huidige voorbeeld voor dit type request is momenteel niet zo realistisch en veelzeggend. De data van de periodes zijn bijvoorbeeld geen echte data, de voorbeeldwaarde is telkens gewoon een string met als tekst "string", ipv een waarde met het dateTime formaat. Ook worden in het voorbeeld voor de attributen 'omleidingen' en 'storingen' exact dezelfde lijsten teruggeven. Wat is dan het verschil tussen de twee? Wat is het verband? Is het mogelijk om voor geefStoringenVoorHalte een duidelijk, realistisch voorbeeld te geven? Ik zou er zelf een zoeken maar ik vind hoe lang ik ook zoek geen enkele halte met storingen. Alvast bedankt.

    Status: Proposed | Reported by Hidden Tue, 23 Jul 2019 11:30:23 GMT
  • geefStoringenVoorHalteLijst heeft verkeerd response schema, voorbeeld en gebroken URLs

    Zowel het voorbeeld als het JSON schema voor de responses van geefStoringenVoorHalteLijst op de pagina https://data.delijn.be/docs/services/KernOpenDataServicesV1/operations/geefStoringenVoorHalteLijst lijken niet te kloppen. Als ik een effectieve request uitvoer krijg ik een JSON object terug met attributen zoals "halteOmleidingen" en "halteToegankelijkheden". Maar in het schema staan deze attributen nergens specififieerd, en lijkt hetgeen wat ik effectief verwacht te ontbreken. Ook zijn de URLs van de link-attributen gebroken. Bijvoorbeeld, HTTP GET van https://api.delijn.be/DLKernOpenData/v1/haltes/2/20433232/lijnrichtingen geeft een 404 terug. De URL moet eigenlijk https://api.delijn.be/DLKernOpenData/api/v1/haltes/2/20433232/lijnrichtingen zijn.

    Status: Proposed | Reported by Hidden Mon, 22 Jul 2019 13:47:36 GMT

You're not signed in. Please sign-in to report an issue or post a comment.