Als je nog niets van NeTEx zou weten...

[Stefan de Konink]

Hoi,

Vanuit het project Data4PT zijn er een aantal suggesties gekomen om toch
iets te gaan doen met informatieve video's over NeTEx. Nu is het doel val
Data4PT om openbaar vervoer bedrijven te helpen met open data in NeTEx en
SIRI (het zal dus in eerste instantie gaan over het produceren van data)
maar ik kan me goed voorstellen dat we ook iets moeten vertellen over het
gebruik er van.

Er zullen hier vast mensen zijn die nog nooit hebben gehoord van NeTEx.
Stel je een situatie voor waar we besluiten morgen te stoppen met KV1 en
GTFS. Wat zou je dan praktisch willen leren?

Vanuit mijn perspectief zou dat een introductie worden in netwerkgegevens
(haltes, lijnen, routes) en daarna de stap naar dienstregelingsgegevens
(rijtijdgroepen, passeertijden, ritten, gegarandeerde overstappen,
omlopen).

Praktisch willen we natuurlijk ook wat doen met code (genereren van code
uit een XSD, strategien om hele grote XML bestanden te verwerken etc.)


Maar misschien sla ik wel wat fundamenteels over...

--
Stefan

[Thomas ten Cate]

Ik ben je doelgroep! Ik weet dat NeTEx komt, dat we ooit over zullen moeten, en dat het XML is, maar daar houdt het wel op.

Naast de onderwerpen die je noemt, zou ik graag nog zien:

- wat de conceptuele verschillen en overeenkomsten zijn met BISON koppelvlakken en GTFS

- waar je de documentatie/specificatie vindt, en met welke bril je die moet lezen

- wat de tijdlijn is voor uitrol

- waar en hoe we de data ophalen

Het zou trouwens mooi zijn als er een de facto standaard library is, of komt, of meerdere, maar in elk geval voor Python. Dan hoeft niet elke afnemer opnieuw met vallen en opstaan het wiel uit te vinden met hun eigen ZeroMQ, envelopes, gzip, afhandeling van verkeerde encoding, stilletjes gedropte verbindingen... en dus ook verwerken van hele grote XML-bestanden.

Video's zijn leuk en aardig maar ik heb liever een geschreven introductie. Dat kun je in je eigen tempo consumeren, en je kunt er makkelijker non-lineair doorheen bewegen. Als dit al bestaat hoor ik het graag :)

--
Je hebt dit bericht ontvangen, omdat je je hebt aangemeld bij de groep 'openov' van Google Groepen.
Als je je wilt afmelden bij deze groep en geen e-mails van de groep meer wilt ontvangen, stuur je een e-mail naar openov+un...@googlegroups.com.
Ga naar https://groups.google.com/d/msgid/openov/23674410-bb8f-4320-9d6a-ee97d38df84a%40konink.de om deze discussie op het internet te bekijken.

[Stefan de Konink]

Hoi Thomas,

On Monday, September 26, 2022 2:14:25 PM CEST, Thomas ten Cate wrote:
> Naast de onderwerpen die je noemt, zou ik graag nog zien:
> - wat de conceptuele verschillen en overeenkomsten zijn met
> BISON koppelvlakken en GTFS

Goede vanuit de Nederlandse context, misschien dat ik de try-out gewoon in
m'n moers taal ga doen ;)

> Het zou trouwens mooi zijn als er een de facto standaard
> library is, of komt, of meerdere, maar in elk geval voor Python.
> Dan hoeft niet elke afnemer opnieuw met vallen en opstaan het
> wiel uit te vinden met hun eigen ZeroMQ, envelopes, gzip,
> afhandeling van verkeerde encoding, stilletjes gedropte
> verbindingen... en dus ook verwerken van hele grote
> XML-bestanden.

Het probleem met NeTEx is dat je het overal voor kan gebruiken. Onze visie
is in de afgelopen 10 jaar geweest dat we onze PostgreSQL-database hebben
ingericht op basis van dat semantische model, maar wel in de context dat we
het in Nederland gebruiken. Het probleem met relationele databases is dat
het niet lekker datamodellen eet die op niet gangbare manieren worden
uitgebreid. En veel extract-transform-load is dan eigenlijk 'te handmatig'.

Als iemand een geniaal idee heeft om een *datastructuur* (bijvoorbeeld
Python Data Classes) op te slaan in een "database" zonder dat het "pickle"
is, ben ik daar erg benieuwd naar. Ik zoek iets dat beter is dan de platte
XML op te slaan. Waar ik graag naar toe zou willen werken is dat je op
basis van de NeTEx XSD kan komen tot een een Object, maar dat de
verwijzingen die een object maakt naar andere objecten lazy kan worden
opgehaald, dat voorkomt immers dat alles in het geheugen moet blijven
staan.

Misschien is een idee wel om alle objecten in een losse tabel te zetten, en
op die manier een graaf op te bouwen... over dit soort architectuur vragen
zou ik graag eens willen nadenken. Los van "de beste manier om grote XML
bestanden te parsen".

> Video's zijn leuk en aardig maar ik heb liever een geschreven
> introductie. Dat kun je in je eigen tempo consumeren, en je kunt
> er makkelijker non-lineair doorheen bewegen. Als dit al bestaat
> hoor ik het graag :)

Ach, een auto-cue tekst kan ook wel op Medium toch? ;)

--
Stefan

[Pellegrom, Simon]

Ik neig naar (ongeveer) dezelfde antwoorden als Thomas. Ik ken het bestaan van NeTEx, heb het een enkele keer gezien bij SNCB (maar besloten eerst voor GTFS te gaan), maar heb er nooit echt in praktische zin mee gewerkt. BISON koppelvlak(ken) ken ik enkel van de vervoerders die daar ook een beetje spoor in stoppen, en dat is dan ook het enige dat ik er uit pluk.

De eerste twee punten van Thomas staan voor mij ook hoog:

- wat de conceptuele verschillen en overeenkomsten zijn met BISON koppelvlakken en GTFS

- waar je de documentatie/specificatie vindt, en met welke bril je die moet lezen

Maar daarnaast zou ik ook graag een houvast vinden in hoe er "snel" een start mee te maken. Waar vind ik de documentatie voor Nederlands OV zonder in een oerwoud van epip-profielen, allerlei land-specifieke implementaties e.d. te belanden. En dan dus, hoe kan ik daar _vandaag_ iets mee doen.

Mijn voorkeur ligt bij (saai, ja...) Java dus een XSD om classes te genereren is zeer gewenst, en misschien kunnen we na verloop enige tips-en-tricks van omgaan met het formaat (als in: omvang) XML e.d. op een praktische manier samenvatten en ergens delen. Idem voor wat Thomas aanhaalt, waar haal ik de data vandaan (vooral ook real-time, de XML op de FTP server vinden we vast wel) en hoe daarmee om te gaan. Maar dat lijkt me een punt voor een paar stappen verder, ik zou eerst triviale dingen met de geplande data willen kunnen doen, en dan daarna daar overheen SIRI toevoegen.

Simon

[Thomas ten Cate]

On Mon, Sep 26, 2022 at 3:59 PM Stefan de Konink <ste...@konink.de> wrote:

> Het zou trouwens mooi zijn als er een de facto standaard
> library is, of komt, of meerdere, maar in elk geval voor Python.
> Dan hoeft niet elke afnemer opnieuw met vallen en opstaan het
> wiel uit te vinden met hun eigen ZeroMQ, envelopes, gzip,
> afhandeling van verkeerde encoding, stilletjes gedropte
> verbindingen... en dus ook verwerken van hele grote
> XML-bestanden.

Het probleem met NeTEx is dat je het overal voor kan gebruiken.

Kun je dat iets specifieker maken? Ik neem aan dat NeTEx geen koffie voor me zet :)

 

Onze visie
is in de afgelopen 10 jaar geweest dat we onze PostgreSQL-database hebben
ingericht op basis van dat semantische model, maar wel in de context dat we
het in Nederland gebruiken. Het probleem met relationele databases is dat
het niet lekker datamodellen eet die op niet gangbare manieren worden
uitgebreid. En veel extract-transform-load is dan eigenlijk 'te handmatig'.

Als iemand een geniaal idee heeft om een *datastructuur* (bijvoorbeeld
Python Data Classes) op te slaan in een "database" zonder dat het "pickle"
is, ben ik daar erg benieuwd naar. Ik zoek iets dat beter is dan de platte
XML op te slaan. Waar ik graag naar toe zou willen werken is dat je op
basis van de NeTEx XSD kan komen tot een een Object, maar dat de
verwijzingen die een object maakt naar andere objecten lazy kan worden
opgehaald, dat voorkomt immers dat alles in het geheugen moet blijven
staan.

Klinkt als een ORM + SQL database. Voor Python heb je SQLAlchemy (ORM quickstart). Werkt behalve met Postgres ook met MySQL en SQLite (handig voor tests). De classes definieer je normaal gesproken in Python, maar die kun je ook prima vanuit een XSD genereren, ofwel eenmalig met code generation, ofwel runtime met metaclasses.

Als NeTEx zich niet leent voor een relationele database (ik begrijp je bezwaar niet helemaal), dan kan zoiets vast ook met een NoSQL database zoals MongoDB, maar dan moet je denk ik (een deel van) de ORM zelf schrijven, en ben je ook niet meer onafhankelijk van het merk van je database.

 

> Video's zijn leuk en aardig maar ik heb liever een geschreven
> introductie. Dat kun je in je eigen tempo consumeren, en je kunt
> er makkelijker non-lineair doorheen bewegen. Als dit al bestaat
> hoor ik het graag :)

Ach, een auto-cue tekst kan ook wel op Medium toch? ;)

Ik ga ook nooit naar de bioscoop, ik lees gewoon lekker thuis op de bank de ondertiteling :P

[Stefan de Konink]

On Monday, September 26, 2022 4:53:57 PM CEST, Thomas ten Cate wrote:
> Het probleem met NeTEx is dat je het overal voor kan gebruiken.
>
> Kun je dat iets specifieker maken? Ik neem aan dat NeTEx geen
> koffie voor me zet :)

De analogie met koffie is dat je er bonen in kan beschrijven, maar ook de
poeder of de nesperesso variant. En er geen voorgekauwd recept is om van
bonen naar branden en malen te komen, maar dat de samenhang allemaal wel
heel logisch lijkt als je ziet dat je de temperatuur of filter grootte
ergens kunt invullen.

Als ik een dienstregeling via passeertijden in NeTEx door zou willen geven
kan dat, als ik de tijden in UTC zou willen doorgeven kan dat, als ik toch
liever rijtijdgroepen gebruik kan dat, maar ik zou ook een enkele rit een
rijtuiggroep kunnen geven, en de rest van de ritten passeerttijden. Er zijn
zoveel varianten dat je afspraken nodig hebt die vastleggen welke varianten
je gaat gebruiken, dat noemen we een profiel. Het zou dus best zo kunnen
zijn dat je uit je planningspakket een ander NeTEx profiel haalt, dan dat
je in je voertuigvolgsysteem stopt, puur om dat de 'view' in het pakket
anders is. De varianten van die views zitten nagenoeg allemaal in NeTEx.

Dan zul je tot de conclusie komen dat het niet gaat om wat je uitwisselt,
maar waarvoor je het (daarna) wilt inzetten. Voor een reisplanner heb je
een hele andere view nodig dan een DRIS systeem.

> Klinkt als een ORM + SQL database. Voor Python heb je
> SQLAlchemy (ORM quickstart). Werkt behalve met Postgres ook met
> MySQL en SQLite (handig voor tests). De classes definieer je
> normaal gesproken in Python, maar die kun je ook prima vanuit
> een XSD genereren, ofwel eenmalig met code generation, ofwel
> runtime met metaclasses.

Er is op dit moment een goede XSD naar Data Classes voor Python (xsdata).
Het onderdeel wat ik niet begrijp hoe je geautomatiseerd een boomstructuur
kunt vastleggen in SQL zodat je daar weer dezelfde boomstructuur uit kan
halen. Dus het gaat me er niet om dat het zich wel of niet zou lenen, ik
denk dat je veel liever een Object Georienteerde database hebt die qua
geheugen transparant is met de objecten in je applicatie.

> Als NeTEx zich niet leent voor een relationele database (ik
> begrijp je bezwaar niet helemaal), dan kan zoiets vast ook met
> een NoSQL database zoals MongoDB, maar dan moet je denk ik (een
> deel van) de ORM zelf schrijven, en ben je ook niet meer
> onafhankelijk van het merk van je database.

Op die manier ga je iedere keer dat je een object pakt, dat object
deserialiseren. Als de objecten klein genoeg zijn, is dat niet per se een
probleem, wat wel een probleem is, is dat sommige objecten in NeTEx een
'samenhang' kennen. Misschien ook eens uit gaan schrijven wat qua
informatica het probleem is. Ik denk dat caching en memory management voor
een NoSQL aanpak een (veel) groter probleem is. Ik realiseer me ook dat als
je referenties wil kunnen ophalen er sowieso wat magie in moet zitten, denk
aan indices.

> Ik ga ook nooit naar de bioscoop, ik lees gewoon lekker thuis
> op de bank de ondertiteling :P

Oh daarom was Tim Kuik zo tegen fan subs ;)

--
Stefan

[Thomas ten Cate]

Zo te zien is de enige reden dat je dit wilt tot nu toe, dat het niet allemaal in RAM past. Hoe groot is die data? De GTFS dienstregelingen van heel Nederland passen tot nu toe nog best in RAM op een gemiddelde machine.

On Mon, Sep 26, 2022 at 5:11 PM Stefan de Konink <ste...@konink.de> wrote:

Op die manier ga je iedere keer dat je een object pakt, dat object
deserialiseren.

Met Cap'n Proto is deserialiseren gratis. Het is een protocol buffers-achtig opslagformaat dat ook goed mapt naar machine architectuur. Je object is gewoon een view op een array van bytes, en het formaat is zo ontworpen dat de getters heel goedkoop zijn.

Maar goed, het gaat vast om meer dan deserializen alleen; die bytes moeten uiteindelijk ook van disk komen (al dan niet via een database server), en dat is waarschijnlijk de echte bottleneck.

 

Als de objecten klein genoeg zijn, is dat niet per se een
probleem, wat wel een probleem is, is dat sommige objecten in NeTEx een
'samenhang' kennen. Misschien ook eens uit gaan schrijven wat qua
informatica het probleem is. Ik denk dat caching en memory management voor
een NoSQL aanpak een (veel) groter probleem is. Ik realiseer me ook dat als
je referenties wil kunnen ophalen er sowieso wat magie in moet zitten, denk
aan indices.

SQLAlchemy kan ook query-resultaten voor je cachen, geloof ik. En kan sowieso indices bouwen, al moet je natuurlijk eenmalig aangeven wat je wilt indexeren.

[Stefan de Konink]

On Monday, September 26, 2022 9:24:36 PM CEST, Thomas ten Cate wrote:
> Zo te zien is de enige reden dat je dit wilt tot nu toe, dat
> het niet allemaal in RAM past. Hoe groot is die data? De GTFS
> dienstregelingen van heel Nederland passen tot nu toe nog best
> in RAM op een gemiddelde machine.

GTFS voor Nederland past ook alleen in RAM als je weet wat je aan het doen
bent. Je zou de Java implementaties van ~5 jaar terug eens moeten zien, die
voor iedere passeertijd een object (64bit referentie + 64bit datatype)
reserveerde. Dan gaat het heel snel in de papieren lopen. Natuurlijk kun je
het ook 'beter' doen, column store aanpak, etc. Ooit gaat dat ook niet meer
werken, en heb je iets nodig dat elegant naar schijf kan (en liefst niet
via swappen).

> On Mon, Sep 26, 2022 at 5:11 PM Stefan de Konink <ste...@konink.de> wrote:
> Op die manier ga je iedere keer dat je een object pakt, dat object
> deserialiseren.
>
> Met Cap'n Proto is deserialiseren gratis. Het is een protocol
> buffers-achtig opslagformaat dat ook goed mapt naar machine
> architectuur. Je object is gewoon een view op een array van
> bytes, en het formaat is zo ontworpen dat de getters heel
> goedkoop zijn.

Er is in Noorwegen wat werk gedaan om NeTEx in Protocol Buffers te krijgen,
met de Java XSD representatie als tussenliggende stap.

> Maar goed, het gaat vast om meer dan deserializen alleen; die
> bytes moeten uiteindelijk ook van disk komen (al dan niet via
> een database server), en dat is waarschijnlijk de echte
> bottleneck.

Vergeet niet: de doorzoekbaarheid.

Er wordt woensdagochtend wat gebrainstormd over video's, laat ik het
resultaat sowieso nog uit horen.

--
Stefan

[Tristan van Triest]

Voor mij zijn alle hierboven beschreven punten goede onderwerpen voor zo'n video.

Vooral kijkende naar het parsen van ingewikkelde (grote) datastructuren van XML naar iets relationeels. Voor bijv de RitInfo berichten van NS heb ik deze handmatig helemaal uitelkaar geplukt tot relationele data om er snel door te kunnen zoeken i.c.m. Postgres, echter om dit weer aan elkaar te plakken zijn zeer grote queries vereist en best veel mapping om het "uit elkaar te trekken", het zal mooi zijn als dat voor NeTEx, zoals je zelf ook aangeeft op een meer gestreamlinede manier kan.

Anderhalf jaar geleden toen ik begon met het werken met OV-data was de GTFS standaard echt een uitkomst, vooral voor een startende developer als ik, CSV, makkelijk uitleesbaar in datastreams en weinig memory overhead. Toen ik vervolgens de stap naar NeTEx wilde maken werd dit al snel een hele klus om te parsen, helemaal met de NodeJS/TS back-end waar ik destijds gebruik van maakte. 

Ook de punten hierboven over documentatie zijn erg belangrijk, het is me vaak overkomen dat ik opzoek wat naar een specifiek punt in de documentatie en 20 bestandjes door moest zoeken om het juiste terug te vinden. Sinds het vinden van  Standaarden | Bison (dova.nu)  is het gelukkig wel makkeljker geworden, maar een mooie goede stap (helemaal voor beginners) is een soort van "stappenplan" met "Click here to start" om het zo maar te zeggen.

Op maandag 26 september 2022 om 21:35:11 UTC+2 schreef ste...@konink.de:

[Stefan de Konink]

On Wednesday, October 5, 2022 6:47:43 PM CEST, Tristan van Triest wrote:
> Vooral kijkende naar het parsen van ingewikkelde (grote) datastructuren van
> XML naar iets relationeels. Voor bijv de RitInfo berichten van NS heb ik
> deze handmatig helemaal uitelkaar geplukt tot relationele data om er snel
> door te kunnen zoeken i.c.m. Postgres, echter om dit weer aan elkaar te
> plakken zijn zeer grote queries vereist en best veel mapping om het "uit
> elkaar te trekken", het zal mooi zijn als dat voor NeTEx, zoals je zelf ook
> aangeeft op een meer gestreamlinede manier kan.

Ik zit zelf meer te denken in de richting van databases die werken op basis
van een voorgedefinieerd object model. Dat mag op basis van geannoteerde
code zijn.

Een van de producten waar ik van weet dat het mee kan is Versant.
<https://en.wikipedia.org/wiki/Versant_Object_Database>

Verder is er op wikipedia nog een waslijst te vinden.
<https://en.wikipedia.org/wiki/Comparison_of_object_database_management_systems>

Ik heb nog even een vraag uitgezet bij iemand die een ander ding gebruikte
voor Java.

Mocht iemand ideeën hebben hoe je data niet relationeel (maar dus ook niet
als losstaand document) het beste kunt opslaan en verwerken, ben ik sowieso
geïnteresseerd.

--
Stefan

[Sven Boor]

Hoi Allemaal,

Ik ben vooral nieuwsgierig of er iets meer uitleg kan komen hoe elke vervoerder zijn NeTEx precies opbouwt. Het zou heel erg fijn zijn als er per vervoerder een index file komt met een verwijzing naar alle NeTEx bestanden die je nodig hebt om de actuele dienstregeling op te bouwen en welke versie van NeTEx wordt gebruikt.

Op het NDOVLoket  zie ik op dit moment dat er data wordt aangeleverd door 4 vervoerders:

http://data.ndovloket.nl/netex/cxx/

http://data.ndovloket.nl/netex/htm/

http://data.ndovloket.nl/netex/arr/

http://data.ndovloket.nl/netex/ret/

Elke vervoerder lijkt de data weer net op een andere manier aan te leveren, in de Bison documentatie staat dat het bijhouden van een index bestand en versieoverzicht de verantwoordelijkheid is van de afnemers, dat vind ik een opmerkelijke keuze aangezien nu alle afnemers dit werk moeten doen terwijl als de vervoerders deze index opbouwen dit maar een keer gedaan hoeft te worden en het voor ontwikkelaars die iets minder diep in de materie zitten (denk aan ontwikkelaars die geen lokale kennis hebben) een stuk eenvoudiger is. Vanuit een afnemers perspectief is hoe eenduidiger hoe beter.

Wat ik daarnaast lastig vind aan NeTEx is dat doordat het op XML gebaseerd is het heel moeilijk is door alleen naar het data bestand te kijken welke data er precies in zit, in KV1 en GTFS is er sprake van een tabel structuur waardoor je zonder naar de documentatie te kijken al een indruk kunt krijgen van hoe de data precies in elkaar zit, bij een XML is dat veel moeilijker. Dat is volgens mij ook een van de belangrijkste redenen dat door ontwikkelaars in deze community tot nu toe veel vaker voor het gebruik van deze standaarden wordt gekozen, het is veel eenvoudiger om ermee te beginnen. Tooling om een NeTEx bestand te exploreren zou heel fijn zijn.

Daarnaast ben ik benieuwd of er plannen zijn vanuit de Nederlandse overheid om ook NeTEx in het EPIP formaat aan te gaan leveren https://data4pt-project.eu/providing-netex-as-open-data-on-a-national-access-point-nap/, eenmalig software schrijven die in een keer in de hele EU toe te passen is zou ideaal zijn. Ook daarvoor zou een index bestand per land die je in een keer verwijst naar de juiste personen heel bruikbaar zijn.

Groet,

Sven

Op maandag 26 september 2022 om 13:02:33 UTC+2 schreef Stefan de Konink:

[Stefan de Konink]

Hoi Sven,

On Thursday, November 17, 2022 11:26:17 AM CET, Sven Boor wrote:
> Ik ben vooral nieuwsgierig of er iets meer uitleg kan komen hoe
> elke vervoerder zijn NeTEx precies opbouwt. Het zou heel erg
> fijn zijn als er per vervoerder een index file komt met een
> verwijzing naar alle NeTEx bestanden die je nodig hebt om de
> actuele dienstregeling op te bouwen en welke versie van NeTEx
> wordt gebruikt.

Bedoel je met opbouw het gebruik van het bestand (wat voor alle Nederlandse
vervoerders hetzelfde zou moeten zijn) of bedoel hoe een vervoerder delen
van zijn data aanlevert bijvoorbeeld per lijn of concessie of regio?

> Elke vervoerder lijkt de data weer net op een andere manier aan
> te leveren, in de Bison documentatie staat dat het bijhouden van
> een index bestand en versieoverzicht de verantwoordelijkheid is
> van de afnemers, dat vind ik een opmerkelijke keuze aangezien nu
> alle afnemers dit werk moeten doen terwijl als de vervoerders
> deze index opbouwen dit maar een keer gedaan hoeft te worden en
> het voor ontwikkelaars die iets minder diep in de materie zitten
> (denk aan ontwikkelaars die geen lokale kennis hebben) een stuk
> eenvoudiger is. Vanuit een afnemers perspectief is hoe
> eenduidiger hoe beter.

Als vervoerders een index aanleveren zou dat toch alleen over hun eigen
data gaan? Lees: je moet als afnemer dan toch nogsteeds aggregeren naar een
landelijk beeld.

> Wat ik daarnaast lastig vind aan NeTEx is dat doordat het op
> XML gebaseerd is het heel moeilijk is door alleen naar het data
> bestand te kijken welke data er precies in zit, in KV1 en GTFS
> is er sprake van een tabel structuur waardoor je zonder naar de
> documentatie te kijken al een indruk kunt krijgen van hoe de
> data precies in elkaar zit, bij een XML is dat veel moeilijker.
> Dat is volgens mij ook een van de belangrijkste redenen dat door
> ontwikkelaars in deze community tot nu toe veel vaker voor het
> gebruik van deze standaarden wordt gekozen, het is veel
> eenvoudiger om ermee te beginnen. Tooling om een NeTEx bestand
> te exploreren zou heel fijn zijn.

Ik kijk er iets anders tegenaan.

1. er zijn in het verleden heel veel varianten van KV1 geweest,
als je iets serieus met KV1 wilde moest je minimaal drie varianten
implementeren (CXX rijtijdgroepen, ARR passeertijden, GVB-index)

2. Je kunt (zelfs met een grep) eenvoudig kijken welke lijnen er in
een NeTEx bestand staan zcat $1 | grep "<Line ", analoog voor
alle andere objecttypes. Pak je het iets beter aan, xsData ->
lxml etree find, partieel deserialiseren. Zo heb ik mijn grafische
NeTEx tool opgebouwd. Het probleem is vervolgens dat je eigenlijk
niet holistisch naar een bestand kijkt, maar alleen een indruk krijgt.

3. Ik geloof er niets van dat mensen de Nederlandse GTFS met de hand(!)
uitlezen. En dat doe je ook niet voor de rijtijdgroepen variant van
KV1.

4. Het echte voordeel van de NL-GTFS is dat het maar 1 bestand is, dat is
ook direct het nadeel. Je moet het hele bestand vervangen als een lijn
is aangepast.

> Daarnaast ben ik benieuwd of er plannen zijn vanuit de
> Nederlandse overheid om ook NeTEx in het EPIP formaat aan te
> gaan leveren
> https://data4pt-project.eu/providing-netex-as-open-data-on-a-national-access-point-nap/,
> eenmalig software schrijven die in een keer in de hele EU toe te
> passen is zou ideaal zijn. Ook daarvoor zou een index bestand
> per land die je in een keer verwijst naar de juiste personen
> heel bruikbaar zijn.

Die zijn er :) Sterker nog: onze exports van Flixbus zijn door een Duits
OV-software bedrijf gecontroleerd en kun je vinden op de open data site van
SBB.

Maar goed, het is allemaal leuk dat wij dit doen. Vorig jaar februari heb
ik gevraagd of mensen gezamenlijk tot een product willen komen... en de
reacties waren oorverdovend stil. Dus ik wacht nu gewoon even tot alle
grote OV-software bedrijven hun NeTEx implementaties af hebben. Weten
vervoerders ook gelijk waar de echte expertise zit.

<https://groups.google.com/g/openov/c/DuAvruauvnU/m/uvZO-KM-AgAJ>

--
Stefan

[Sven Boor]

Hoi Stefan,

Bedoel je met opbouw het gebruik van het bestand (wat voor alle Nederlandse vervoerders hetzelfde zou moeten zijn) of bedoel hoe een vervoerder delen van zijn data aanlevert bijvoorbeeld per lijn of concessie of regio?

Ik bedoel het tweede. 

Elke vervoerder lijkt de data weer net op een andere manier aan te leveren, in de Bison documentatie staat dat het bijhouden van een index bestand en versieoverzicht de verantwoordelijkheid is van de afnemers, dat vind ik een opmerkelijke keuze aangezien nu alle afnemers dit werk moeten doen terwijl als de vervoerders deze index opbouwen dit maar een keer gedaan hoeft te worden en het voor ontwikkelaars die iets minder diep in de materie zitten (denk aan ontwikkelaars die geen lokale kennis hebben) een stuk eenvoudiger is. Vanuit een afnemers perspectief is hoe eenduidiger hoe beter.

Als vervoerders een index aanleveren zou dat toch alleen over hun eigen data gaan? Lees: je moet als afnemer dan toch nogsteeds aggregeren naar een landelijk beeld.

Ja ik bedoel het per vervoerder inderdaad, op dit moment moet je zelf de logica ontwaren.

Wat ik daarnaast lastig vind aan NeTEx is dat doordat het op XML gebaseerd is het heel moeilijk is door alleen naar het data bestand te kijken welke data er precies in zit, in KV1 en GTFS is er sprake van een tabel structuur waardoor je zonder naar de documentatie te kijken al een indruk kunt krijgen van hoe de data precies in elkaar zit, bij een XML is dat veel moeilijker. Dat is volgens mij ook een van de belangrijkste redenen dat door ontwikkelaars in deze community tot nu toe veel vaker voor het gebruik van deze standaarden wordt gekozen, het is veel eenvoudiger om ermee te beginnen. Tooling om een NeTEx bestand te exploreren zou heel fijn zijn.

Ik kijk er iets anders tegenaan.

1. er zijn in het verleden heel veel varianten van KV1 geweest,
  als je iets serieus met KV1 wilde moest je minimaal drie varianten    implementeren (CXX rijtijdgroepen, ARR passeertijden, GVB-index)

Klopt, maar je bent het denk ik wel met mij eens dat vanuit het oogpunt van standaardisatie je wil dat er in een standaard voor een van deze varianten wordt gekozen toch? 

2. Je kunt (zelfs met een grep) eenvoudig kijken welke lijnen er in
  een NeTEx bestand staan zcat $1 | grep "<Line ", analoog voor
  alle andere objecttypes. Pak je het iets beter aan, xsData ->    lxml etree find, partieel deserialiseren. Zo heb ik mijn grafische
  NeTEx tool opgebouwd. Het probleem is vervolgens dat je eigenlijk
  niet holistisch naar een bestand kijkt, maar alleen een indruk krijgt.

Ja dat holistische overzicht heb ik persoonlijk meer bij een KV1 of GTFS, maar dat is uiteindelijk gedeeltelijk voorkeur en gewenning. 

3. Ik geloof er niets van dat mensen de Nederlandse GTFS met de hand(!)
  uitlezen. En dat doe je ook niet voor de rijtijdgroepen variant van KV1.

Dat is wel hoe ik zelf werkte toen ik er mee ontwikkelde, in de GTFS of KV1 zie ik veel sneller hoe alles precies in elkaar klikt.

4. Het echte voordeel van de NL-GTFS is dat het maar 1 bestand is, dat is
  ook direct het nadeel. Je moet het hele bestand vervangen als een lijn
  is aangepast.

Daarnaast ben ik benieuwd of er plannen zijn vanuit de Nederlandse overheid om ook NeTEx in het EPIP formaat aan te gaan leveren https://data4pt-project.eu/providing-netex-as-open-data-on-a-national-access-point-nap/, eenmalig software schrijven die in een keer in de hele EU toe te passen is zou ideaal zijn. Ook daarvoor zou een index bestand per land die je in een keer verwijst naar de juiste personen heel bruikbaar zijn.

Waarom ik hier personen schrijf is me een raadsel, ik bedoelde natuurlijk bestanden ;-). 

Die zijn er :) Sterker nog: onze exports van Flixbus zijn door een Duits OV-software bedrijf gecontroleerd en kun je vinden op de open data site van SBB.

Waar kan ik die precies vinden? Zoeken op Flixbus geeft helaas geen resultaat https://data.sbb.ch/pages/home/

Maar goed, het is allemaal leuk dat wij dit doen. Vorig jaar februari heb ik gevraagd of mensen gezamenlijk tot een product willen komen... en de reacties waren oorverdovend stil. Dus ik wacht nu gewoon even tot alle grote OV-software bedrijven hun NeTEx implementaties af hebben. Weten vervoerders ook gelijk waar de echte expertise zit.

<https://groups.google.com/g/openov/c/DuAvruauvnU/m/uvZO-KM-AgAJ>

Het blijft toch een beetje een kip en ei verhaal helaas, zolang de data die als NeTEx (liefst EPIP) beschikbaar is nog beperkt is (zowel binnen Nederlands als daar buiten).

Groet,

Sven

 

--
Stefan

--
Je hebt dit bericht ontvangen, omdat je je hebt aangemeld bij een onderwerp in de groep 'openov' van Google Groepen.
Als je je wilt afmelden bij dit onderwerp, ga je naar https://groups.google.com/d/topic/openov/0qOuNzG6_gE/unsubscribe.
Als je je wilt afmelden bij deze groep en alle onderwerpen van de groep, stuur je een e-mail naar openov+un...@googlegroups.com.
Ga naar https://groups.google.com/d/msgid/openov/e8098d6c-be0b-4c90-b8bb-9494f0c2d88e%40konink.de om deze discussie op het internet te bekijken.

[Stefan de Konink]

On Thursday, November 17, 2022 12:36:38 PM CET, Sven Boor wrote:
> Ik bedoel het tweede.

In mijn beeld is dit 'geregeld'. Ik ben overigens recent van geloof
veranderd en denk dat lijnleveringen (in tegenstelling tot 1 bestand) het
voor iedereen wel eens beter zou kunnen maken. Dat zou betekenen dat je
gewoon een XML bestandje binnen krijgt en daarmee de vorige lijn vervangt.
Voor een aantal toepassingen met omlopen is dit minder geschikt, maar voor
reisinformatie kun je hiermee hele mooie overzichtjes rond wijzigingen
maken.

> Klopt, maar je bent het denk ik wel met mij eens dat vanuit het
> oogpunt van standaardisatie je wil dat er in een standaard voor
> een van deze varianten wordt gekozen toch?

Uiteraard, maar dat is met het Nederlandse NeTEx Profiel in mijn optiek ook
gebeurt. Een compacte serialisatie van kalenders (analoog aan KV1
passeertijden), een gecomprimeerde dienstregeling beschrijving (analoog aan
KV1 rijtijdgroepen). Directe koppeling naar CHB via PassengerStopAssignment
in NeTEx. Dus ik zie op het beschrijvende formaat eigenlijk niet zo veel
wijzigingen. Je moet weten welke partities er zijn, en kunt dan iedere keer
een nieuw bestand in die partitie gooien.

> Die zijn er :) Sterker nog: onze exports van Flixbus zijn door
> een Duits OV-software bedrijf gecontroleerd en kun je vinden op
> de open data site van SBB.
> Waar kan ik die precies vinden? Zoeken op Flixbus geeft helaas
> geen resultaat https://data.sbb.ch/pages/home/

<https://opentransportdata.swiss/de/dataset/netex-fernbus>

> <https://groups.google.com/g/openov/c/DuAvruauvnU/m/uvZO-KM-AgAJ>
> Het blijft toch een beetje een kip en ei verhaal helaas, zolang
> de data die als NeTEx (liefst EPIP) beschikbaar is nog beperkt
> is (zowel binnen Nederlands als daar buiten).

Er staat al jaren NeTEx data van HTM, Arriva en Transdev op het loket. Net
doen alsof dat niet zo is, is een eigen realiteit creeeren. Je hoeft geen
voorhoede speler te zijn, maar na de wedstrijd proberen te scoren is
nogal... suf.

--
Stefan

[Alexander Overvoorde]

Als afnemer van de GTFS data verrast het mij eigenlijk niet zo erg dat er tot nu toe een gebrek aan enthousiasme is voor NeTEx. De GTFS standaard bestaat al een lange tijd en er is zowel op nationaal en internationaal gebied heel veel gereedschap ontwikkeld om hier goed mee te werken. De data zit op een logische manier in elkaar en is makkelijk te verwerken met relationele databases. Het kan wel zo zijn dat dat model minder past bij hoe de brondata oorspronkelijk aangeleverd wordt, maar voor mij als ontwikkelaar is het altijd makkelijk geweest om met het eindproduct (gtfs-nl.zip) te werken en valt er eigenlijk weinig over te klagen.

Dat NeTEx een verbetering is vergeleken met standaarden zoals KV1 geloof ik graag, maar ik heb het vermoeden dat er weinig afnemers zijn die direct met deze bestanden werken. Voor de meeste applicaties werkt gtfs-nl.zip eigenlijk gewoon zodanig goed dat er geen reden is om naar de bronbestanden te kijken. Ik vind het dan ook opmerkelijk dat de eerste e-mail in deze discussie begint met "Stel je een situatie voor waar we besluiten morgen te stoppen met KV1 en GTFS", wat suggereert dat NeTEx voor de afnemers hier alleen een bestaansrecht heeft wanneer de huidige oplossingen verdwijnen.

Ik wil hiermee niet bij voorbaat stellen dat NeTEx een slechte ontwikkeling is, maar eerder dat het verkooppraatje op dit moment niet aankomt. Daarom zou ik willen afsluiten met mijn eigen stelling: stel dat de huidige gtfs-nl.zip vanaf morgen gegenereerd wordt vanuit NeTEx bestanden (aangenomen dat deze beschikbaar zijn voor alle vervoerders), waarom zou de doorsnee afnemer dan iets met de NeTEx bestanden zelf willen doen?

--
Je hebt dit bericht ontvangen, omdat je je hebt aangemeld bij de groep 'openov' van Google Groepen.
Als je je wilt afmelden bij deze groep en geen e-mails van de groep meer wilt ontvangen, stuur je een e-mail naar openov+un...@googlegroups.com.
Ga naar https://groups.google.com/d/msgid/openov/878c4535-abd1-4c84-bedb-39483c27ef2b%40konink.de om deze discussie op het internet te bekijken.

[Stefan de Konink]

On Monday, November 21, 2022 10:36:19 PM CET, Alexander Overvoorde wrote:
> stel dat de huidige
> gtfs-nl.zip vanaf morgen gegenereerd wordt vanuit NeTEx bestanden
> (aangenomen dat deze beschikbaar zijn voor alle vervoerders), waarom zou de
> doorsnee afnemer dan iets met de NeTEx bestanden zelf willen doen?

Ik denk dat dat de verkeerde 'aanleiding' is. Natuurlijk kunnen GTFS en KV1
bestanden gemaakt worden uit NeTEx bestanden. Het "gewoon zodanig goed"
omschrijft waarschijnlijk wat er mis gaat. Het is niet alleen "zodanig
goed" maar wordt gebruikt op een niveau waarbij de verwachting is ontstaan
dat die GTFS-export ook met van alles is te koppelen wat niet in het
GTFS-ecosysteem zit. Het feit dat er op die manier wordt gekoppeld (lees:
KV6) vind ik ook echt heel boeiend. Niet omdat ik de functionele wens niet
snap om zo snel mogelijk voertuigposities te krijgen, wel dat de luiheid er
is ingeslopen dat niemand onder de gebruikers in bijna 10 jaar denkt: "goh,
laat ik eens een standaardisatievoorstel voor GTFS-RT DIFFERENTIAL via
websockets indienen".

Het lijkt er op dat de aanlevering van "beter dan goed" GTFS er voor zorgt
dat bij een aantal partijen ook maar is gestopt met participeren en
ontwikkelen.

We zijn nu op een punt uitgekomen dat het argument voor ontwikkelaars om
niet mee te doen met nieuwe ontwikkeling wordt gedreven door: "er is al
bijna 10 jaar een betrouwbaar ander formaat en dat vind ik wel best, ik
hoef niets nieuws meer te leren". Of commercieel: "iemand anders regelt het
wel voor ons."

Vandaar de aanleiding: wat als het er morgen niet meer is?

Nu gaf Thomas ten Cate aan dat een standaard library een van de
interessante dingen is, maar ook dat gaat er vanuit dat 'iemand anders het
wel even voor je gaat maken' en niet dat het een 'gezamenlijk initiatief'
is.

--
Stefan

[Alexander Overvoorde]

Het is niet alleen "zodanig
goed" maar wordt gebruikt op een niveau waarbij de verwachting is ontstaan
dat die GTFS-export ook met van alles is te koppelen wat niet in het
GTFS-ecosysteem zit. Het feit dat er op die manier wordt gekoppeld (lees:
KV6) vind ik ook echt heel boeiend. Niet omdat ik de functionele wens niet
snap om zo snel mogelijk voertuigposities te krijgen, wel dat de luiheid er
is ingeslopen dat niemand onder de gebruikers in bijna 10 jaar denkt: "goh,
laat ik eens een standaardisatievoorstel voor GTFS-RT DIFFERENTIAL via
websockets indienen".

Ik kan niet voor alle afnemers spreken, maar ik kan wel toelichten hoe die situatie voor mij persoonlijk ontstaan is.

Toen ik de eerste versie van ovzoeker bouwde, onderzocht ik waar ik de dienstregeling en live updates vandaan kon halen. Als ik het mij goed herinner bestonden de GTFS-RT bestanden toen nog niet, dus voor live updates waren de KV6/KV78turbo/etc. streams de enige optie. Vervolgens moest ik een keuze maken of ik de dienstregeling uit de bronbestanden (KV1, ...) ging inlezen of de GTFS varianten van Thomas ging gebruiken. Eerlijk gezegd was die keuze toen snel gemaakt, omdat GTFS goed gedocumenteerd is, als CSV formaat makkelijk in te laden is, en je makkelijk kan debuggen door in een gewone teksteditor direct naar de bestanden te kijken. Zeker omdat ik toen nog geen enkele ervaring met de OV gegevens had, waren dat belangrijke eigenschappen tijdens het ontwikkelen van een eerste applicatie.

Nadat ik de eerste in elkaar gehackte versie een beetje zat was, begon ik ovzoeker volledig te herschrijven en stond ik opnieuw voor de keuze hoe ik met de gegevens wilde omgaan. Ik heb toen een aantal mogelijkheden bekeken, waarvan de eerste was om vanaf nu direct met de bronbestanden te gaan werken, zodat ik zo goed als mogelijk de ruwe data op de website kon gaan aanbieden, mijn uitgangspunt is namelijk altijd geweest om de data zo direct en onbewerkt mogelijk weer te geven (en geen dingen zoals interpolatie e.d. te gaan doen). Ik liep echter tegen het probleem aan dat er veel verschillende formaten in loop waren en dat zelfs binnen een formaat als KV1 de vervoerders allemaal verschillende manieren gebruikten om hun dienstregeling vast te leggen. Ik was er op dat moment van overtuigd (en eigenlijk op dit moment nog steeds) dat er eigenlijk alleen maar met die data te werken zou zijn, als het eerst omgezet wordt naar een gestandardiseerde en gedenormaliseerde vorm die makkelijk in een standaard database te verwerken is. Die vorm bestond echter al en heeft de naam GTFS en zo kwam ik opnieuw bij de GTFS data uit. Ik realiseerde mij op dat moment wel dat het een risico zou zijn om ervan uit te gaan dat velden zoals realtime_trip_id altijd in diezelfde vorm zouden blijven bestaan. Daarop besloot ik dat de beste aanpak zou zijn om de software van Thomas zelf te draaien en desnoods te forken om precies de GTFS te genereren die ik zelf verwachtte. Uiteindelijk lukte het echter niet goed om de software zelf te draaien. Ik weet niet precies meer waarom, of het aan documentatie of fouten/gebrek aan kennis van mijzelf lag, maar ik kon het in ieder geval niet goed werkend krijgen. Daarna heb ik nog korte tijd geprobeerd om zelf conversie software te schrijven voor alle standaarden, maar daar ben ik eerlijk gezegd heel snel van teruggekomen omdat aanvoelde als een eindeloze bende aan uitzonderingen. Daarmee ook hulde aan Thomas voor het ontwikkelen, draaien en onderhouden van de software zoals die al deze jaren bestaan heeft. De enige optie die dus voor mij overbleef was om door te gaan met de GTFS bestanden die op ovapi.nl gehost worden.

Wat betreft de realtime data was er echter in de tussentijd wat veranderd. Naast de statische GTFS data stonden er nu ook GTFS-RT dumps op ovapi.nl. Ik heb overwogen om deze te gebruiken, maar ik liep tegen het probleem aan dat deze data alleen maar aangeboden werden in de vorm van "snapshots" van alle voertuigstatussen die je eens in de zoveel tijd moet downloaden. Deze vorm van distributie maakt het niet mogelijk om updates van voertuigen te ontvangen zodra ze beschikbaar komen, dus je loopt altijd achter de feiten aan. Maar... als je toch al een manier hebt om die GTFS-RT bestanden te genereren en elke X seconden in een map te zetten, dan is het triviaal om die wijzigingen over een WebSocket of ZMQ socket te publiceren. Daarom stuurde ik toendertijd een e-mail om voor te stellen om de data ook over een WebSocket aan te bieden. De reactie die ik hierop kreeg kwam er echter op neer dat het allemaal heel ingewikkeld was en niet ging gebeuren.

Als gevolg daarvan heb ik zelf code geschreven die KV6 en andere data in een GTFS-RT stream omzet en jarenlang heb ik met succes op die manier allerlei producten kunnen ontwikkelen. De reden dat ik die code al die jaren niet geopensourced heb is omdat het vanuit mijn perspectief niet veel meer was dan een hercreatie van wat Thomas al gebouwd had voor ovapi.nl met het enige kleine verschil dat mijn code de geproduceerde GTFS-RT updates over een socket publiceert in plaats van ze naar een bestand te schrijven. Voor mij kwam het neer op weinig meer dan een "hack" om arbitraire limitaties van een bestaande oplossing te overwinnen.

Terwijl ik dit schrijf ben ik nog steeds van mening dat ovapi.nl 99% van de oplossing aanbiedt, maar om een voor mij onduidelijke reden, niet die laatste 1% mogelijk maakt, waardoor er in een klap niet langer een reden zou zijn om KV6 met GTFS te koppelen.

Het lijkt er op dat de aanlevering van "beter dan goed" GTFS er voor zorgt
dat bij een aantal partijen ook maar is gestopt met participeren en
ontwikkelen.

We zijn nu op een punt uitgekomen dat het argument voor ontwikkelaars om
niet mee te doen met nieuwe ontwikkeling wordt gedreven door: "er is al
bijna 10 jaar een betrouwbaar ander formaat en dat vind ik wel best, ik
hoef niets nieuws meer te leren". Of commercieel: "iemand anders regelt het
wel voor ons."

 

 Vandaar de aanleiding: wat als het er morgen niet meer is?

Nu gaf Thomas ten Cate aan dat een standaard library een van de
interessante dingen is, maar ook dat gaat er vanuit dat 'iemand anders het
wel even voor je gaat maken' en niet dat het een 'gezamenlijk initiatief'
is.

Ik vind dat hier wel heel snel conclusies getrokken worden.

Niemand hier twijfelt aan het belang van wat er al die jaren gratis via ovapi.nl aangeboden is. Ik kan oprecht zeggen dat als die GTFS data er niet was geweest, dat ik waarschijnlijk nooit iets met de OV data had gedaan. Tegelijkertijd is er in deze community nooit om hulp gevraagd bij de ontwikkeling of hosting. Tenzij je goed zoekt is het ook eigenlijk niet eens echt duidelijk dat het hier om een open source project gaat, maar eerder als een extra service die semi-officieel vanuit het NDOVloket aangeboden wordt om het makkelijker te maken om met de OV data aan de slag te gaan. Geen nieuws wordt nou eenmaal doorgaans opgevat als goed nieuws, dus ik vind het oneerlijk om jarenlang stilletjes ovapi.nl aan te bieden en dan vervolgens te klagen dat niemand bijdraagt wanneer daar nooit eerder iets over gezegd is.

Als er hulp nodig is bij het verder ontwikkelen en onderhouden van de GTFS, bijvoorbeeld om ondersteuning voor NeTEx bronbestanden toe te voegen, dan sta ik er helemaal voor open om hieraan bij te dragen en ik denk dat dat ook geldt voor andere afnemers. Ook een eventuele financiële bijdrage voor de ontwikkeling is natuurlijk mogelijk. Een voorwaarde is dat er dan wel veel duidelijker gecommuniceerd wordt wat er precies verwacht wordt van de afnemers.

--
Je hebt dit bericht ontvangen, omdat je je hebt aangemeld bij de groep 'openov' van Google Groepen.
Als je je wilt afmelden bij deze groep en geen e-mails van de groep meer wilt ontvangen, stuur je een e-mail naar openov+un...@googlegroups.com.

Ga naar https://groups.google.com/d/msgid/openov/2306147f-36d0-4e58-8096-082edb6e934a%40konink.de om deze discussie op het internet te bekijken.

[pascalg...@gmail.com]

Dit is eigenlijk ook precies hoe het bij mij is gegaan. Als GTFS niet bestond was ik waarschijnlijk nooit in het OV data wereldje gerold en had ik waarschijnlijk zelfs niet mijn eerste development baantje gehad. Na veel losse eilandjes aan informatie aan elkaar gepuzzeld te hebben ben ik uiteindelijk bij GTFS terecht gekomen, welke ik uiteindelijk kon combineren met realtime informatie vanaf KV6. 

Ik ben ook groot fan van GTFS omdat je het simpelweg in een database knikkert, en je direct vanaf die database je implementaties kan draaien. Hoewel er vast goede use-cases zijn voor NeTEx en KV1, zijn NeTEx en KV1 niet zo 'plug and play' als GTFS aangezien je het zelf zal moeten omzetten in een werkend formaat. Het enige grote nadeel aan GTFS is dat er weinig interoperabiliteit is met andere datasets/realtime data die vrijwel essentieel is. 

Stops.txt in de huidige GTFS bestanden is geen goede manier om gegroepeerde vertrektijden te krijgen van een compleet busstation met meerdere vervoerders. Daarnaast is het CHB ook niet koppelbaar met GTFS waardoor je de grote trukendoos open moet trekken om maar iets met gegroepeerde haltes te doen. Mijn hack destijds was om om alle haltes een geofence met een marge te maken. Alle haltes die dan binnen die geofence vielen hoorden bij elkaar. Het geringe aantal edge cases (meerdere verdiepingen of halten dicht bij elkaar) werden hardcoded opgelost. Het was geen mooie oplossing maar het werkte wel. KV6 valt op zich goed te koppelen met GTFS mits je zelf de realtime_trip_id opbouwt vanuit de waarden in KV6.

Na de mening van anderen gehoord te hebben, mijn eigen ervaringen bij elkaar opgeteld en high-traffic implementaties die in productie staan gezien (en mee gewerkt) te hebben denk ik dat er vooral behoefte is aan een setje aan realtime en statische GTFS(RT) data. Voor mijn gevoel wilt bijna iedereen die aan de slag wilt met OV-data het liefst werken met de GTFS standaarden en daarom denk ik dat we met z'n allen beter tijd kunnen investeren in dat bereiken dan 40 keer het wiel opnieuw uitvinden met eigen NeTEx implementaties. 

Naar mijn mening komen we denk ik al een heel eind als we: 

- Een GTFS bestand hebben als één source of truth (voor zover dat kan)

- Een GTFS-RT stream via WebSockets. Iets zoals dat van Alexander zou fantastisch zijn om open-source te hebben. GTFS-RT werkt namelijk beter samen dan met koppelvlakken en in de praktijk heb ik gemerkt dat ZeroMQ niet altijd lekker (of helemaal niet) werkt met bepaalde programmeertalen omdat je met native bindings te maken hebt. Daarnaast is elke minuut het Protobuf file downloaden natuurlijk niet de meest efficiënte optie.

- Het CBH geïntegreerd kan worden in GTFS of tenminste samen werkt met GTFS zodat we niet allemaal onze eigen hacky oplossingen in elkaar beunen. 

Dit is allemaal natuurlijk allemaal makkelijker gezegd dan gedaan. Maar behalve als iemand hele specifieke implementaties heeft om specifieke data te verkrijgen denk ik dat 99% van de projecten al een heel eind komen als we de bovengenoemde punten kunnen realiseren. Nog mooier als we dit samen doen (en open-sourcen). Ik ben in ieder geval bereid om tijd te steken in het toegankelijker maken van OV data, is het niet door een totaalplaatje te maken met de GTFS standaarden, dan wel op een andere manier waar we met veel mensen achter staan. Dan blijft het werken met OV data leuk. 🙂

[Stefan de Konink]

On Wednesday, November 23, 2022 9:41:27 PM CET, Alexander Overvoorde wrote:
> Toen ik de eerste versie van ovzoeker bouwde, onderzocht ik waar ik de
> dienstregeling en live updates vandaan kon halen. Als ik het mij goed
> herinner bestonden de GTFS-RT bestanden toen nog niet, dus voor live
> updates waren de KV6/KV78turbo/etc.

ovzoeker.nl is geregisteerd in oktober 2013. Ik weet zeker dat er op dat
moment al GTFS-RT was. Ik heb het zelfs nagezocht in een conversatie tussen
Thomas Koch en Andrew Byrd een jaar eerder in 2012. Overigens: op dezelfde
URL als nu.

> Maar... als je toch al een manier hebt om die GTFS-RT bestanden te
> genereren en elke X seconden in een map te zetten, dan is het triviaal om
> die wijzigingen over een WebSocket of ZMQ socket te publiceren. Daarom
> stuurde ik toendertijd een e-mail om voor te stellen om de data ook over
> een WebSocket aan te bieden. De reactie die ik hierop kreeg kwam er echter
> op neer dat het allemaal heel ingewikkeld was en niet ging gebeuren.

Het probleem is, dat het niet triviaal is om het op grote schaal te doen.
Sinds 2013 draaien we naar aanleiding van een standaardisatie overleg met
Brian Ferris een websocket feed. En die websocket feed werd op dat moment
ook gebruikt om OpenTripPlanner realtime bij te werken (in plaats van met
snapshots voor Google Maps of rrrr).

Waarom is het niet triviaal voor tripUpdates.pb.

1. Je hebt een volledige snapshot nodig om te starten.
2. Er mag geen ruimte zitten tussen de eerste websocket update en die
snapshot
3. Om het publiceren echt schaalbaar te maken moet je de berichten op een
pubsub achtige manier asynchroon naar een websocket distributie keten
sturen. Daarna heb je uiteraard nog wat problemen als slow-subscriber
op
te lossen.
4. DIFFERENTIAL is nog steeds niet gestandaardiseerd.


Waarom het voor vehiclePositions.pb wel kan werken: je gaat er vanuit dat
binnen een minuut toch wel een update komt. Terwijl als je een cancel hebt
gemist, je nat gaat.

Nu hebben we een aantal scenario's bedacht om 'schaalbaar' in sync te
komen. Denk aan eerst upgraden naar websockets, en te bufferen tot de
timestamp van de volgende snapshot, maar triviaal is het allemaal niet en
on de fly genereren van protobuf bestanden van 2.5MB is ook een CPU sloper.

>> Nu gaf Thomas ten Cate aan dat een standaard library een van de
>> interessante dingen is, maar ook dat gaat er vanuit dat 'iemand anders het
>> wel even voor je gaat maken' en niet dat het een 'gezamenlijk initiatief'
>> is.
>>
>
> Ik vind dat hier wel heel snel conclusies getrokken worden.

Ik vind dat ik na 1 jaar toch echt die conclusie wel mag trekken.

<https://groups.google.com/g/openov/c/DuAvruauvnU/m/a_cl7cYTAwAJ>

> Niemand hier twijfelt aan het belang van wat er al die jaren gratis via
> ovapi.nl aangeboden is. Ik kan oprecht zeggen dat als die GTFS data er niet
> was geweest, dat ik waarschijnlijk nooit iets met de OV data had gedaan.
> Tegelijkertijd is er in deze community nooit om hulp gevraagd bij de
> ontwikkeling of hosting. Tenzij je goed zoekt is het ook eigenlijk niet
> eens echt duidelijk dat het hier om een open source project gaat, maar
> eerder als een extra service die semi-officieel vanuit het NDOVloket
> aangeboden wordt om het makkelijker te maken om met de OV data aan de slag
> te gaan.

Het gaat commercieel niet om het hosten of maken van GTFS. GoAbout sponsort
al jaren een server. De tandem daarvan wordt door OVapi en Bliksem Labs
betaald. Formeel is het een gesponsorde dienst aan Stichting OpenGeo die,
met dank aan ACC ICT, ook NDOVloket.nl draait met een degelijke SLA.

Het gaat mijns zins ook niet over het gebruik van GTFS. Ik heb daar van de
week met iemand van SBB een uitgebreid gesprek over gehad. NeTEx is geen
religie en als jij alles kan doen met GTFS moet je dat vooral gebruiken.
Wij zien grote problemen met GTFS, zeker voor nieuwe vormen van openbaar
vervoer, maar ook suffe dingen als het correct representeren "je mag je
fiets buiten de spits meenemen". Daarnaast wil Google met alle liefde de
stekker uit de workarounds trekken en geeft geen optie om GBFS (tenzij je
via ITO World gaat) of GOFS aan te leveren.

> Geen nieuws wordt nou eenmaal doorgaans opgevat als goed nieuws,
> dus ik vind het oneerlijk om jarenlang stilletjes ovapi.nl aan te bieden en
> dan vervolgens te klagen dat niemand bijdraagt wanneer daar nooit eerder
> iets over gezegd is.

Toen ik met dit project begon in 2009 had ik wel de verwachting dat er
dingen gingen gebeuren. Die zijn natuurlijk ook gebeurd. Je eigen website
is er een voorbeeld van, OVinfo, OpenTripPlanner, de treinloggers, ...


Gezien er nu een greenfield kans ligt (introductie van een nieuwe
dienstregeling standaard en straks realtime in SIRI voor alle vervoerders),
waar de kaarten opnieuw geschud worden, vind ik het ontzettend jammer dat
dit voor geen enkele partij een aanleiding was om SAMEN eens wat te doen.


--
Stefan

[Stefan de Konink]

On Wednesday, November 23, 2022 10:47:46 PM CET, pascalg...@gmail.com
wrote:

> Stops.txt in de huidige GTFS bestanden is geen goede manier om gegroepeerde
> vertrektijden te krijgen van een compleet busstation met meerdere
> vervoerders. Daarnaast is het CHB ook niet koppelbaar met GTFS waardoor je
> de grote trukendoos open moet trekken om maar iets met gegroepeerde haltes
> te doen. Mijn hack destijds was om om alle haltes een geofence met een
> marge te maken. Alle haltes die dan binnen die geofence vielen hoorden bij
> elkaar. Het geringe aantal edge cases (meerdere verdiepingen of halten
> dicht bij elkaar) werden hardcoded opgelost. Het was geen mooie oplossing
> maar het werkte wel. KV6 valt op zich goed te koppelen met GTFS mits je
> zelf de realtime_trip_id opbouwt vanuit de waarden in KV6.

stops.txt is een groot compromis. Zeker als je beschouwt dat de koppeling
met realtime data er ook nog eens afhankelijk van is. Maar goed, NeTEx
(PassengerStopAssignment) zou wellicht ook weer een zetje kunnen geven in
de goede richting.

> Na de mening van anderen gehoord te hebben, mijn eigen ervaringen bij
> elkaar opgeteld en high-traffic implementaties die in productie staan
> gezien (en mee gewerkt) te hebben denk ik dat er vooral behoefte is aan een
> setje aan realtime en statische GTFS(RT) data. Voor mijn gevoel wilt bijna
> iedereen die aan de slag wilt met OV-data het liefst werken met de GTFS
> standaarden en daarom denk ik dat we met z'n allen beter tijd kunnen
> investeren in dat bereiken dan 40 keer het wiel opnieuw uitvinden met eigen
> NeTEx implementaties.

Waarom zou Noorwegen in OpenTripPlanner2 dan /wel/ met NeTEx en SIRI
werken?

--
Stefan

[Tristan van Triest]

Hi all,

Ook ik wilde toch nog even mijn eigen beredenering voor het gebruik van GTFS toevoegen.

Zoals Stefan wel zal hebben gemerkt, ben ik er namelijk ook eentje die BISON standaarden aan GTFS heeft gekoppeld, en dat heeft aan het begin eigenlijk maar 1 reden gehad: duidelijkheid van de data. GTFS is zoals eerder vermeld een heel duidelijk beschreven standaard welke makkelijk te implementeren is. Ik was vooraf niet bekend met bestaande GTFS implementaties, dus ik gebruik tot op de dag van vandaag nog steeds een zelf geschreven CSV-parser. Dit toont maar weer aan hoe "makkelijk" het is om met GTFS te werken.

Zo'n anderhalf jaar geleden ben ik begonnen met het werken met OV data op advies van een vriend die destijds bij Qbuzz als technicus werkte en inmiddels is doorgegroeid naar de IT afdeling. Hij liet mij weten dat er veel data in het OV beschikbaar was, en dit bleek ook zo te zijn! Hij stuurde mij naar het NDOVLoket, maar hier vond ik veel informatie zonder echt een goede uitleg "how to get started" so to say. Toen ben ik zelf een beetje gaan googlen en dan kom je al snel op de GTFS bestanden van OVApi/OpenOV uit (het verschil tussen deze twee is mij overigens nog steeds niet helemaal duidelijk). 

Mijn eerste "hacky" implementatie begon met KV6, puur KV6 met niets anders. Maar ja, je wilt toch wat meer kunnen laten zien dan een lijnplannummer i.c.m. een ritnummer. Wetende dat de GTFS bestond ben ik daar als eerste naar toe gesneld (KV1 was nog out-of-the-picture). Zo is bij mij in eerste instantie de koppeling tussen KV6 en realtime_trip_id in GTFS ontstaan. Dit gaat goed, totdat je Arriva's treinen krijgt, maar dat is inmiddels duidelijk via NS InfoPlus!  (echter zijn dit soort vragen die meer mensen zullen hebben denk ik makkelijk op te lossen door een "vaste" Q&A/Beginners Guide ergens te hebben, want hoe vaak heeft Stefan wel niet aan mij en vele andere mensen verteld dat KV6 en GTFS koppelen geen goed plan is? ;) ) 

Ik denk dat (helemaal voor beginners) het belangrijk is om een soort van "getting started" guide met best-practices op te zetten, helemaal zodra NeTeX een (nog) grotere rol gaat spelen in de OV data wereld. Aan het begin van mijn reis met OV data (en nog steeds) waren er veel dode links (o.a. naar connekt.nl), of niet-geupdate bestanden (neem REALTIME.txt waar nog gesproken word over "Syntus" i.p.v. "KEOLIS" als enveloppe of waar de DAS enveloppe totaal niet in beschreven staat.). 

Deze verwarring heeft mij overgehaald om GTFS te blijven gebruiken voor een (veel te lange) tijd. 

Pas recentelijk ben ik gaan kijken naar de data die bijvoorbeeld vanuit KV1 in KV7 terecht komt (neem Lines, Destinations) ipv het matchen op GTFS ritten. Echter, zoals in een eerdere post beschreven, mist dat dan ook weer wat data (zoals agencyId, wat ik nu maar heb gelinkt aan het "LinePublicNumber" naar de "routeShortName" in de GTFS en daar de agencyId uit haal). NeTex is dan natuurlijk nog een heel ander "beest", waar ik al vaak naar heb gekeken en mee heb gespeeld maar tot op heden nog niet tot een realistische implementatie ben gekomen.

Een lang verhaal om eigenlijk te zeggen dat er zoveel data beschikbaar is, dat je als beginner de bomen door het bos niet meer ziet. Daarom is het belangrijk om voor NeTeX duidelijk te maken hoe en wat er "verwacht" van je word als "afnemer". Helemaal omdat NeTeX zoals hierboven al eerder gesteld een moeilijke standaard is die niet zo 123 te parsen is als GTFS. Ik sta er zelf helemaal voor open om hier ook een steentje aan bij te dragen, omdat ik vind wat wij hier in Nederland hebben met OpenOV/NDOV-loket iets is waar vele andere landen nog van kunnen leren qua open-data betreft. Zonder deze community had ik nooit de interesse in OV-data gekregen die ik nu heb, en had ik er al helemaal niet mijn toekomstige baan van willen maken.

Thanks,
Tristan

Op woensdag 23 november 2022 om 23:02:15 UTC+1 schreef ste...@konink.de:

[Tristan van Triest]

P.S.

Zelf kijk ik al gelange tijd uit naar de nieuwe NeTeX en SIRI standaarden, omdat ik daarmee hoop op een iets wat meer "cohesief" verhaal. (Zover ik begrijp zijn NeTeX en SIRI echt ontwikkeld om samen met elkaar te werken/gebruikt te worden met dezelfde termen en structuur?). Met KV1 & KV6 merkte ik vaak (zoals ook eerder gesteld) dat vervoerders hun eigen draai er aan geven. (Neem bijvoorbeeld het "KV6PosInfo" veld van KV6. Soms is dit een Array met Arrays erin, soms een object met arrays erin, soms een object met objecten erin, dit zijn allemaal van die kleine afwijkingen welke makkelijk bugs kunnen introduceren.)

Op donderdag 24 november 2022 om 11:52:38 UTC+1 schreef Tristan van Triest:

[Stefan de Konink]

On Thursday, November 24, 2022 11:52:38 AM CET, Tristan van Triest wrote:
> Hij stuurde mij
> naar het NDOVLoket, maar hier vond ik veel informatie zonder
> echt een goede uitleg "how to get started" so to say.

Geeft ook wel aan hoe lang er een bepaald LaTeX bestandje niet is afgemaakt
;)

> Toen ben
> ik zelf een beetje gaan googlen en dan kom je al snel op de GTFS
> bestanden van OVApi/OpenOV uit (het verschil tussen deze twee is
> mij overigens nog steeds niet helemaal duidelijk).

Het verschil tussen die twee is ook historisch ontstaan. Voor Google Maps
was het in het verleden noodzakelijk om exact op landsgrenzen data aan te
bieden. Over een paar weken is dat niet meer nodig. openov-nl is dus
'alleen Nederland' terwijl er in de OVapi variant alle data zit die op dat
moment in de Reisinformatie Database is ingeladen.

> (echter zijn dit soort
> vragen die meer mensen zullen hebben denk ik makkelijk op te
> lossen door een "vaste" Q&A/Beginners Guide ergens te hebben,

LaTeX klinkt als NeTEx en neemt minstens even veel tijd in om goed te doen
;)

> Zelf kijk ik al gelange tijd uit naar de nieuwe NeTeX en SIRI
> standaarden, omdat ik daarmee hoop op een iets wat meer
> "cohesief" verhaal. (Zover ik begrijp zijn NeTeX en SIRI echt

> ontwikkeld om samen met elkaar te werken/gebruikt te worden met
> dezelfde termen en structuur?).

Het probleem wat op dat vlak onstaat is de broninformatie zelf. HTM, RET,
GVB en in zekere zin Qbuzz en Arriva hebben SIRI in hun
voertuigvolgsystemen, maar de input van die voertuigvolgsystemen is (nog)
geen NeTEx. De integratie van SIRI naar NeTEx bestaat uit eenzelfde soort
referentie als 'trip_id' in GTFS-RT. Dus om dat goed te doen met de juiste
identifiers moet er ook weer gehobbied worden omdat een voertuigvolgsysteem
bijvoorbeeld alleen een nummertje aan kan als ritidentificatie, terwijl we
in NeTEx hebben afgesproken dat het ARR:ServiceJourney:1234 moet zijn.

> Met KV1 & KV6 merkte ik vaak
> (zoals ook eerder gesteld) dat vervoerders hun eigen draai er
> aan geven. (Neem bijvoorbeeld het "KV6PosInfo" veld van KV6.
> Soms is dit een Array met Arrays erin, soms een object met
> arrays erin, soms een object met objecten erin, dit zijn
> allemaal van die kleine afwijkingen welke makkelijk bugs kunnen
> introduceren.)

Vandaar m'n opmerking over greenfield. 1 strakke implementatie zorgt er ook
voor dat je een gesprekspartner wordt bij de validatie van de gegevens.

--
Stefan

[Tristan van Triest]

>Geeft ook wel aan hoe lang er een bepaald LaTeX bestandje niet is afgemaakt

Heb je hier wellicht ergens een in-progress versie van welke ik in zal kunnen zien?

>LaTeX klinkt als NeTEx en neemt minstens even veel tijd in om goed te doen

Dat is een bekende zaak haha! Allebij hele enge woorden om te horen, vooral LaTeX op academisch gebied :P

Op donderdag 24 november 2022 om 12:11:16 UTC+1 schreef ste...@konink.de:

[Stefan de Konink]

On Thursday, November 24, 2022 12:19:19 PM CET, Tristan van Triest wrote:
>> Geeft ook wel aan hoe lang er een bepaald LaTeX bestandje niet
>> is afgemaakt
>
> Heb je hier wellicht ergens een in-progress versie van welke ik in zal
> kunnen zien?

In de bijlage ;)

>> LaTeX klinkt als NeTEx en neemt minstens even veel tijd in om goed te doen
>
> Dat is een bekende zaak haha! Allebij hele enge woorden om te horen, vooral
> LaTeX op academisch gebied :P

Ja, het op de muur smeren is een stuk eenvoudiger...

--
Stefan

[Tristan van Triest]

Thanks!

> Ja, het op de muur smeren is een stuk eenvoudiger...

Geen ervaring mee tot dusver helaas!

Appreciate deze mooie claim: "Deze beschrijving gaat ver voorbij de meeste nationale reis planners, waar een aankomst- of vertreklocatie met een aan- of vertrektijd al wordt gepresenteerd als wereldwonder."

Credit where credit is due, dit document zit tot dusver zeer goed in elkaar en als beginner had ik hier zeker iets aan gehad, dus het is zeker een mooi begin! 

Pratende over IFF, ik heb hier mijn hoofd vaak over gebroken. Zijn er uberhaupt mensen die volledig snappen hoe die standaard werkt? Het document beschrijft het als een tamelijk oude standaard, maar is er wel ergens een publieke implementatie beschikbaar voor het uitlezen? Of zeg je houd het op de 3 dagen van NS Infoplus en bespaar je tijd?

Ook word er in het document tot dusver niet echt gesproken over KV7/8 Turbo; dus voor nu de vraag even hier tussendoor (mijn excuses): op  Index of / (openov.nl) zijn historische kv7 bestanden te vinden, deze gebruik ik nog wel eens om gemiste data te importeren als mijn service een paar dagen offline is geweest. Momenteel doe ik dit d.m.v. een download exentie in chrome welke alle gz files handmatig download. Is er een efficientere manier om deze bestanden programmatisch in te laden? Again, sorry voor de afwijking van het topic!

Iniedergeval bedankt voor het tonen van dit bestand, dit is namelijk precies wat ik bedoelde en het toont maar weer dat er hard aan gewerkt word om OV data meer beginner friendly te maken :)

Tristan

Op donderdag 24 november 2022 om 12:26:41 UTC+1 schreef ste...@konink.de:

[Stefan de Konink]

On Thursday, November 24, 2022 12:48:03 PM CET, Tristan van Triest wrote:
> Thanks!
>> Ja, het op de muur smeren is een stuk eenvoudiger...
> Geen ervaring mee tot dusver helaas!
>
> Appreciate deze mooie claim: "Deze beschrijving gaat ver
> voorbij de meeste nationale reis planners, waar een aankomst- of
> vertreklocatie met een aan- of vertrektijd al wordt
> gepresenteerd als wereldwonder."

Het is ook echt waar. Als je deze standaard als reisplanner implementeert,
dan kunnen je gebruikers echt veel meer.

<https://github.com/VDVde/OJP/>

> Credit where credit is due, dit document zit tot dusver zeer
> goed in elkaar en als beginner had ik hier zeker iets aan gehad,
> dus het is zeker een mooi begin!

Jammer eigenlijk dat het dus al weer een jaar in de schoenendoos zat.

> Pratende over IFF, ik heb hier mijn hoofd vaak over gebroken.
> Zijn er uberhaupt mensen die volledig snappen hoe die standaard
> werkt?

Jazeker, ik heb de e-mail adressen van de originele ontwerpers ;) Wij
hebben IFF in Java en Python draaien. Ik heb zelfs een IFF naar NeTEx
converter ;)

> Het document beschrijft het als een tamelijk oude
> standaard, maar is er wel ergens een publieke implementatie
> beschikbaar voor het uitlezen? Of zeg je houd het op de 3 dagen
> van NS Infoplus en bespaar je tijd?

NS heeft al aangegeven dat ze naar NeTEx wil, ik zou het echt niet
implementeren tenzij je tijd over hebt.

> Ook word er in het document tot dusver niet echt gesproken over
> KV7/8 Turbo; dus voor nu de vraag even hier tussendoor (mijn
> excuses): op Index of / (openov.nl) zijn historische kv7
> bestanden te vinden, deze gebruik ik nog wel eens om gemiste
> data te importeren als mijn service een paar dagen offline is
> geweest. Momenteel doe ik dit d.m.v. een download exentie in
> chrome welke alle gz files handmatig download. Is er een
> efficientere manier om deze bestanden programmatisch in te
> laden? Again, sorry voor de afwijking van het topic!

Als hier nog geen (S)FTP variant van is, wil ik dat ook wel beschikbaar
(gaan) stellen.

> Iniedergeval bedankt voor het tonen van dit bestand, dit is
> namelijk precies wat ik bedoelde en het toont maar weer dat er
> hard aan gewerkt word om OV data meer beginner friendly te maken
> :)

Mocht er nou iemand zijn die bijvoorbeeld projectmanager richting wil geven
aan dit geheel, of de voortgang te bewaken. Ook dat soort functies zouden
zeer worden gewaardeerd.

Het is echt niet dat wij aan het hobbien zijn met NeTEx om maar niets aan
beginnerdocumentatie te hoeven doen... ;)

--
Stefan

[Pellegrom, Simon]

IFF is nou ook weer niet zo complex imo, maar het kost vooral tijd om goed te doorgronden. Ik kan me voorstellen dat dat een hobbel is voor nieuwe afnemers. Conversie naar GTFS lijkt me goed, maar er gaat wel informatie verloren. 

In het buitenland tref je hetzelfde, BELTAC in België is ook een stuk antiek bijvoorbeeld. Waarbij er toevallig iemand​ GTFS doet, al is de GTFS van vervoerders ook lang niet altijd werkbaar. Zie SNCB met “stop time overrides” omdat men geen spoorwijzigingen levert bijvoorbeeld. Die moet je er zelf in hacken door de API te gaan pollen. Wat weer HAFAS openAPI is met eigen journey ID’s. Ik overweeg inmiddels om (tegen de licentie in) m’n eigen feeds maar aan te gaan bieden aan de buitenwereld. 

---

From: ope...@googlegroups.com <ope...@googlegroups.com> on behalf of Tristan van Triest <trista...@gmail.com>
Sent: Thursday, November 24, 2022 12:48:03 PM
To: openov <ope...@googlegroups.com>
Subject: Re: [openov] Als je nog niets van NeTEx zou weten...

 

--
Je hebt dit bericht ontvangen omdat je bent geabonneerd op de groep 'openov' van Google Groepen.

Als je je wilt afmelden bij deze groep en geen e-mails van de groep meer wilt ontvangen, stuur je een e-mail naar openov+un...@googlegroups.com.

Ga naar https://groups.google.com/d/msgid/openov/d02463de-54a3-4cfe-9e78-dc5f762893ban%40googlegroups.com om deze discussie op internet te bekijken.

[Stefan de Konink]

On Thursday, November 24, 2022 2:21:48 PM CET, Pellegrom, Simon wrote:
> IFF is nou ook weer niet zo complex imo, maar het kost vooral
> tijd om goed te doorgronden. Ik kan me voorstellen dat dat een
> hobbel is voor nieuwe afnemers. Conversie naar GTFS lijkt me
> goed, maar er gaat wel informatie verloren.

In de NeTEx-IFF heb ik een poging gedaan om het meeste over te nemen in de
vorm zoals het nu in IFF staat. Ik heb overigens hetzelfde gevoel bij veel
HAFAS TEXT exports waar veel HAFAS-attributen over gedeeltes van ritten
veel uitgebreider zijn dan GTFS (of wat men in NeTEx EPIP exporteert). Dat
geldt overigens ook voor vertalingen.

> In het buitenland tref je hetzelfde, BELTAC in België is ook
> een stuk antiek bijvoorbeeld.

Brings back memories ;)

> Waarbij er toevallig iemand​ GTFS
> doet, al is de GTFS van vervoerders ook lang niet altijd
> werkbaar. Zie SNCB met “stop time overrides” omdat men geen
> spoorwijzigingen levert bijvoorbeeld. Die moet je er zelf in
> hacken door de API te gaan pollen. Wat weer HAFAS openAPI is met
> eigen journey ID’s. Ik overweeg inmiddels om (tegen de licentie
> in) m’n eigen feeds maar aan te gaan bieden aan de
> buitenwereld.

Gewoon doen. Deed iRail niet ook al iets?

--
Stefan

[Pellegrom, Simon]

Dat “vooral doen” is ook m’n plan idd, maar moet het nog een beetje bijschaven voor de buitenwereld. iRail doet een aantal dingen, en erg goed, maar ik zou veel meer push-based willen. Of in ieder geval een model waarin niet iedereen, separaat, een webservice van een vervoerder aan het bestoken is. Heb wel contact met de mensen daar inmiddels.

Het is zo’n heerlijke stap terug in de tijd hier idd :)

---

From: ope...@googlegroups.com <ope...@googlegroups.com> on behalf of Stefan de Konink <ste...@konink.de>
Sent: Thursday, November 24, 2022 2:26:41 PM
To: ope...@googlegroups.com <ope...@googlegroups.com>

Subject: Re: [openov] Als je nog niets van NeTEx zou weten...

--
Je hebt dit bericht ontvangen, omdat je je hebt aangemeld bij de groep 'openov' van Google Groepen.

Als je je wilt afmelden bij deze groep en geen e-mails van de groep meer wilt ontvangen, stuur je een e-mail naar openov+un...@googlegroups.com.

Ga naar https://groups.google.com/d/msgid/openov/e96b87a9-eddc-477e-b483-813eff51a5e9%40konink.de om deze discussie op het internet te bekijken.

[Stefan de Konink]

On Thursday, November 24, 2022 2:29:59 PM CET, Pellegrom, Simon wrote:
> Dat “vooral doen” is ook m’n plan idd, maar moet het nog een
> beetje bijschaven voor de buitenwereld. iRail doet een aantal
> dingen, en erg goed, maar ik zou veel meer push-based willen. Of
> in ieder geval een model waarin niet iedereen, separaat, een
> webservice van een vervoerder aan het bestoken is. Heb wel
> contact met de mensen daar inmiddels.

Dit klinkt als precies dezelfde aanleiding voor de OV-fiets poller. Een
persoon pulled, dan op een servicebus zetten.

--
Stefan

[Pellegrom, Simon]

Ja de gedachtegang is hetzelfde idd. Ik heb geen moeite met een NMBS service bestoken, als ze willen janken moeten ze GTFS-RT maar fixen. Maar als we het dan zoveel als mogelijk kunnen samenvoegen zodat niet iedereen, separaat dat hoeft te doen, lijkt me dat netjes. 

We mailen nog wel eens off-list anders, ben de boel hier nu off-topic aan het maken, sorry! 

---

From: ope...@googlegroups.com <ope...@googlegroups.com> on behalf of Stefan de Konink <ste...@konink.de>

Sent: Thursday, November 24, 2022 2:35:21 PM

To: ope...@googlegroups.com <ope...@googlegroups.com>
Subject: Re: [openov] Als je nog niets van NeTEx zou weten...

--
Je hebt dit bericht ontvangen, omdat je je hebt aangemeld bij de groep 'openov' van Google Groepen.
Als je je wilt afmelden bij deze groep en geen e-mails van de groep meer wilt ontvangen, stuur je een e-mail naar openov+un...@googlegroups.com.

Ga naar https://groups.google.com/d/msgid/openov/72924dac-cbf0-4122-883f-74bc7096d658%40konink.de om deze discussie op het internet te bekijken.

[Tristan van Triest]

>NS heeft al aangegeven dat ze naar NeTEx wil, ik zou het echt niet
>implementeren tenzij je tijd over hebt.

Dat is duidelijk, tijd heb ik zeker niet te veel, dus dan laat ik dat voor nu even liggen. Ik neem wel aan dat dat nog een behoorlijke tijd kan duren voordat de NS over gaat?

>Als hier nog geen (S)FTP variant van is, wil ik dat ook wel beschikbaar
>(gaan) stellen.

Dat zal ik zelf heel erg waarderen. Ik heb het zelf (nog) niet op de FTP service kunnen vinden en met FTP naar dat domein verbinden leek niet te werken.

>Mocht er nou iemand zijn die bijvoorbeeld projectmanager richting wil geven
>aan dit geheel, of de voortgang te bewaken. Ook dat soort functies zouden
>zeer worden gewaardeerd.

Als ik er wat meer kennis over had gehad had ik dat zeker willen doen, maar als degene die hier vooral de vragen stelt in plaats van beantwoord lijkt dat me een beetje onhandig ;)

Op donderdag 24 november 2022 om 14:37:53 UTC+1 schreef Simon Pellegrom:

[Stefan de Konink]

On Thursday, November 24, 2022 3:08:06 PM CET, Tristan van Triest wrote:
>>NS heeft al aangegeven dat ze naar NeTEx wil, ik zou het echt niet
>>implementeren tenzij je tijd over hebt.
>
> Dat is duidelijk, tijd heb ik zeker niet te veel, dus dan laat
> ik dat voor nu even liggen. Ik neem wel aan dat dat nog een
> behoorlijke tijd kan duren voordat de NS over gaat?

Dat klopt, maar er loopt een plannentje om NeTEx beschikbaar te gaan
stellen voor data dat nog niet in NeTEx staat. Analoog aan het maken van
GTFS.

>>Mocht er nou iemand zijn die bijvoorbeeld projectmanager richting wil geven
>>aan dit geheel, of de voortgang te bewaken. Ook dat soort functies zouden
>>zeer worden gewaardeerd.
>
> Als ik er wat meer kennis over had gehad had ik dat zeker
> willen doen, maar als degene die hier vooral de vragen stelt in
> plaats van beantwoord lijkt dat me een beetje onhandig ;)

Als projectmanager hoef je toch ook alleen maar te vragen 'wanneer is het
klaar'? ;)

--
Stefan