Issues

  • 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
  • GTFS Static data

    Heb intussen reeds 2 maal de procedure doorlopen via het online form om de static data aan te vragen. 1.5 maand verder geen enkel antwoord (los van de auto-reply), dan maar nog eens langs deze weg proberen. Licentie tevens in bijlage.

    Status: Proposed | Reported by Hidden Tue, 09 Jul 2019 11:07:01 GMT
  • vtnum parameter verdwenen

    Er moet precies een update geweest zijn, de realtime info wordt anders ingedeeld (nog één element per array), en de variabele "vtnum" is helaas verdwenen.

    Status: Proposed | Reported by Hidden Tue, 09 Jul 2019 10:02:56 GMT
  • Doorkomsten soms dubbel

    Aan sommige haltes worden bepaalde doorkomsten dubbel getoond. Komt vaak voor met trams, maar in het voorbeeld in bijlage zijn het ook soms bussen. (misschien te maken met soort stiptheidshaltes?) Ik ga er van uit dat per ritnummer slechts één doorkomst zou mogen zijn.

    Status: Proposed | Reported by Hidden Mon, 08 Jul 2019 07:19:25 GMT
  • HTTP 200 maar geen doorkomsten

    Hoi, op dit moment doe ik deze call: ttps://delijn.azure-api.net/DLKernOpenData/api/v1/haltes/lijst/2_205358_2_201144_2_201242_2_205921_2_205919_2_211128_2_200144_2_202350_2_205915_2_205916/real-time. Die geeft 200 terug, maar er zitten geen doorkomsten in de lijst. Ik zie dat de officiële De Lijn app hetzelfde probleem heeft. Is het niet mogelijk om in het geval van een achterliggend probleem, toch een HTTP foutcode te geven?

    Status: Proposed | Reported by Hidden Tue, 04 Jun 2019 04:39:45 GMT
  • Confirmation email "Give feedback" points to Google

    The confirmation email when you create an account has a button 'give feedback' which is linking to Google.

    Status: Proposed | Reported by Hidden Mon, 25 Feb 2019 19:27:50 GMT
  • Is het mogelijk om "lijnnummerPubliek" toe te voegen aan geefDoorkomstenVoorHalte

    Ik kreeg van enkele gebruikers de melding dat mijn toepassing foutieve tram/busnummers weergeeft. Als ik voor de halte 200064 (entiteit 2) opzoek bij MijnLijn.be/200064 krijg ik als eerste bus/trams de 76, 2, 71, 4, 42... (zie bijlage) Als ik dezelfde halte via de nieuwe API oproep krijg ik: 176, 102, 171, 40, 142 terug... Het lijkt erop dat dit enkel in OV (entiteit 2) gebeurt. In Antwerpen is de lijnnummer op het eerste zicht altijd gelijk aan de publieke lijnnummer. Nu vind ik terug dat er een "getLijn" is welke de lijn-nummer als input heeft en de publieke nummer weergeeft, maar gezien de limieten is het jammer dat hiervoor een losse call nodig is. Uiteraard kunnen we deze data cachen, daar ik vermoed dat de deze mapping vrij statisch is, maar, zou het mogelijk zijn om de lijnnummerPubliek ook bij geefDoorkomstenVoorHalte (etc) weer te geven? Dat zou de implementatie vereenvoudigen en bij deze calls is de publieke lijnnr vaak nodig. Met vriendelijke groeten, Jelle

    Status: Open | Reported by Hidden Mon, 25 Feb 2019 19:25:13 GMT
  • Concept vervoersregio toevoegen

    Is het mogelijk om vervoersregio's toe te voegen aan de API. Dus iets in de zin van GeefGemeentesVoorVervoersregio? En/of GeefLijnenVoorVervoersregio...

    Status: Proposed | Reported by Hidden Fri, 15 Feb 2019 09:27:50 GMT

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