NeTEx voor het spoor

223 views
Skip to first unread message

Stefan de Konink

unread,
Jun 2, 2024, 12:02:59 PM6/2/24
to openov
Hoi,


Ik weet niet meer hoe vaak ik de IFF nu precies heb geïmplementeerd,
maar het is nog steeds net op een hand te tellen. Ik hoop echter dat
niemand dit ooit nog hoeft te doen, want ik heb een NeTEx bestand
gemaakt. Vrijwel alle functionaliteit uit IFF zit er in (mits NS het
levert). Het is belangrijk om te realiseren dat dit een 1:1 vertaling
van IFF naar NeTEx is en dus niet 'compatibel' is met de Nederlandse
NeTEx standaard of EPIP standaard.


Je kunt het downloaden via:

<https://data.publicationdelivery.eu/iff/nl/NeTEx_IFF_IFF_22_23_24_25v2.xml.gz>

Nieuwe versies komen in hetzelfde mapje.


Het doel:
- het mogelijk maken dat realtime data te koppelen is
- validatie van een aantal belangrijke spoorse dingen
(splitsen en samenvoegen)
- een afgeleide export in het Nederlandse NeTEx-profiel
- een afgeleide export in het European Passenger Information Profile
- het combineren van de EPIAP export


--
Stefan
OpenPGP_0xDA0A21EE7E3D2959.asc
OpenPGP_signature.asc

Tristan van Triest

unread,
Jun 2, 2024, 12:28:23 PM6/2/24
to openov

Je bent een held! Het is dat ik nog bezig ben met afstuderen anders had ik linea recta dit voor R-OV geïmplementeerd. Een mooie stap, hoef ik nooit meer aan IFF te denken (hopelijk)… 
Op zondag 2 juni 2024 om 18:02:59 UTC+2 schreef ste...@konink.de:

Stefan de Konink

unread,
Jun 2, 2024, 1:54:59 PM6/2/24
to ope...@googlegroups.com
Op 6/2/24 om 18:28 schreef Tristan van Triest:
> Je bent een held! Het is dat ik nog bezig ben met afstuderen anders had
> ik linea recta dit voor R-OV geïmplementeerd. Een mooie stap, hoef ik
> nooit meer aan IFF te denken (hopelijk)…

Omdat ik wist dat mensen blij zouden worden van perronniveau data heb ik
ook alle perrons uniek gemaakt, inclusief overstap relaties. Voor de
kenners onder ons. De attributen etc. met first-last-stop beschrijvingen
zijn gerealiseerd door JourneyParts te maken waarbij op iedere
JourneyPart de verwachtte juiste attributen zitten en dus ook op
perronniveau beschreven zijn. Dat geldt ook voor alle interchange rules
die in IFF op station niveau zijn beschreven, maar ik nu ingezoomd op
perronniveau heb geëxporteerd.

Als hier nog mensen zijn die treinnummers weten waarmee edge cases
kunnen worden test hoor ik dat ook graag.

--
Stefan

OpenPGP_0xDA0A21EE7E3D2959.asc
OpenPGP_signature.asc

Arilith

unread,
Jun 2, 2024, 2:03:33 PM6/2/24
to ope...@googlegroups.com
421 en 10421 zijn denk ik wel de grootste edge case. Nightjet word op een ingewikkelde manier opgesplitst in InfoPlus.


> Op 2 jun 2024 om 19:55 heeft Stefan de Konink <ste...@konink.de> het volgende geschreven:
>
> Op 6/2/24 om 18:28 schreef Tristan van Triest:
> --
> 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/cca27ccb-242e-4be1-8a23-6f58ba544a74%40konink.de om deze discussie op het internet te bekijken.
> <OpenPGP_0xDA0A21EE7E3D2959.asc>

Stefan de Konink

unread,
Jun 2, 2024, 2:43:13 PM6/2/24
to ope...@googlegroups.com
Op 6/2/24 om 20:03 schreef Arilith:
> 421 en 10421 zijn denk ik wel de grootste edge case. Nightjet word op een ingewikkelde manier opgesplitst in InfoPlus.


Nou dit bak ik er dus van :) Ik ben ook nog wel benieuwd naar een rit
waar een tijdzone wisseling in zit.


<ServiceJourney id="DCRI:ServiceJourney:2194" version="0201">
<validityConditions>
<AvailabilityConditionRef version="0201"
ref="DCRI:AvailabilityCondition:0"/>
</validityConditions>
<TransportMode>rail</TransportMode>
<TypeOfProductCategoryRef version="0201"
ref="DCRI:TypeOfProductCategory:NJ"/>
<RouteRef version="0201" ref="DCRI:Route:53521"/>
<OperatorRef version="0201" ref="DCRI:Operator:200"/>
<trainNumbers>
<TrainNumberRef version="0201" ref="DCRI:TrainNumber:421"/>
<TrainNumberRef version="0201" ref="DCRI:TrainNumber:40421"/>
</trainNumbers>
<parts>
<JourneyPart id="DCRI:JourneyPart:2194-1-3" version="0201" order="1">
<TrainNumberRef version="0201" ref="DCRI:TrainNumber:421"/>
<FromStopPointRef version="0201"
ref="DCRI:ScheduledStopPoint:asd-10"/>
<ToStopPointRef version="0201" ref="DCRI:ScheduledStopPoint:ht-6a"/>
<StartTime>19:00:00</StartTime>
<EndTime>20:11:00</EndTime>
<TypeOfProductCategoryRef version="0201"
ref="DCRI:TypeOfProductCategory:NJ"/>
</JourneyPart>
<JourneyPart id="DCRI:JourneyPart:2194-3-4" version="0201" order="2">
<FromStopPointRef version="0201"
ref="DCRI:ScheduledStopPoint:ht-6a"/>
<ToStopPointRef version="0201" ref="DCRI:ScheduledStopPoint:koln"/>
<StartTime>20:14:00</StartTime>
<EndTime>22:23:00</EndTime>
</JourneyPart>
<JourneyPart id="DCRI:JourneyPart:2194-4-12" version="0201" order="3">
<TrainNumberRef version="0201" ref="DCRI:TrainNumber:40421"/>
<FromStopPointRef version="0201" ref="DCRI:ScheduledStopPoint:koln"/>
<ToStopPointRef version="0201" ref="DCRI:ScheduledStopPoint:wbf"/>
<StartTime>22:27:00</StartTime>
<EndTime>09:17:00</EndTime>
<EndTimeDayOffset>1</EndTimeDayOffset>
</JourneyPart>
</parts>
<calls>
<Call id="DCRI:TimetabledPassingTime:2194-1" version="0201" order="1">
<ScheduledStopPointRef version="0201"
ref="DCRI:ScheduledStopPoint:asd-10"/>
<Departure>
<Time>19:00:00</Time>
</Departure>
</Call>
<Call id="DCRI:TimetabledPassingTime:2194-2" version="0201" order="2">
<ScheduledStopPointRef version="0201"
ref="DCRI:ScheduledStopPoint:ut-14"/>
<Arrival>
<Time>19:28:00</Time>
</Arrival>
<Departure>
<Time>19:34:00</Time>
</Departure>
</Call>
<Call id="DCRI:TimetabledPassingTime:2194-3" version="0201" order="3">
<ScheduledStopPointRef version="0201"
ref="DCRI:ScheduledStopPoint:ht-6a"/>
<Arrival>
<Time>20:11:00</Time>
</Arrival>
<Departure>
<Time>20:14:00</Time>
</Departure>
</Call>
<Call id="DCRI:TimetabledPassingTime:2194-4" version="0201" order="4">
<ScheduledStopPointRef version="0201"
ref="DCRI:ScheduledStopPoint:koln"/>
<Arrival>
<Time>22:23:00</Time>
</Arrival>
<Departure>
<Time>22:27:00</Time>
</Departure>
</Call>
<Call id="DCRI:TimetabledPassingTime:2194-5" version="0201" order="5">
<ScheduledStopPointRef version="0201"
ref="DCRI:ScheduledStopPoint:wurzb"/>
<Arrival>
<Time>02:26:00</Time>
<DayOffset>1</DayOffset>
</Arrival>
<Departure>
<Time>02:29:00</Time>
<DayOffset>1</DayOffset>
</Departure>
</Call>
<Call id="DCRI:TimetabledPassingTime:2194-6" version="0201" order="6">
<ScheduledStopPointRef version="0201"
ref="DCRI:ScheduledStopPoint:nurnb"/>
<Arrival>
<Time>03:28:00</Time>
<DayOffset>1</DayOffset>
</Arrival>
<Departure>
<Time>04:08:00</Time>
<DayOffset>1</DayOffset>
</Departure>
</Call>
<Call id="DCRI:TimetabledPassingTime:2194-7" version="0201" order="7">
<ScheduledStopPointRef version="0201"
ref="DCRI:ScheduledStopPoint:regenb"/>
<Arrival>
<Time>05:07:00</Time>
<DayOffset>1</DayOffset>
</Arrival>
<Departure>
<Time>05:09:00</Time>
<DayOffset>1</DayOffset>
</Departure>
</Call>
<Call id="DCRI:TimetabledPassingTime:2194-8" version="0201" order="8">
<ScheduledStopPointRef version="0201"
ref="DCRI:ScheduledStopPoint:pass"/>
<Arrival>
<Time>06:13:00</Time>
<DayOffset>1</DayOffset>
</Arrival>
<Departure>
<Time>06:15:00</Time>
<DayOffset>1</DayOffset>
</Departure>
</Call>
<Call id="DCRI:TimetabledPassingTime:2194-9" version="0201" order="9">
<ScheduledStopPointRef version="0201"
ref="DCRI:ScheduledStopPoint:wels"/>
<Arrival>
<Time>07:14:00</Time>
<DayOffset>1</DayOffset>
</Arrival>
<Departure>
<Time>07:16:00</Time>
<DayOffset>1</DayOffset>
</Departure>
</Call>
<Call id="DCRI:TimetabledPassingTime:2194-10" version="0201"
order="10">
<ScheduledStopPointRef version="0201"
ref="DCRI:ScheduledStopPoint:linz"/>
<Arrival>
<Time>07:44:00</Time>
<DayOffset>1</DayOffset>
</Arrival>
<Departure>
<Time>07:47:00</Time>
<DayOffset>1</DayOffset>
</Departure>
</Call>
<Call id="DCRI:TimetabledPassingTime:2194-11" version="0201"
order="11">
<ScheduledStopPointRef version="0201"
ref="DCRI:ScheduledStopPoint:polten"/>
<Arrival>
<Time>08:38:00</Time>
<DayOffset>1</DayOffset>
</Arrival>
<Departure>
<Time>08:40:00</Time>
<DayOffset>1</DayOffset>
</Departure>
</Call>
<Call id="DCRI:TimetabledPassingTime:2194-12" version="0201"
order="12">
<ScheduledStopPointRef version="0201"
ref="DCRI:ScheduledStopPoint:wbf"/>
<Arrival>
<Time>09:17:00</Time>
<DayOffset>1</DayOffset>
</Arrival>
</Call>
</calls>
</ServiceJourney>

--
Stefan

OpenPGP_0xDA0A21EE7E3D2959.asc
OpenPGP_signature.asc

Thomas ten Cate

unread,
Jul 30, 2024, 5:59:49 AM7/30/24
to ope...@googlegroups.com
Dit is fijn, hartelijk dank! Kunnen we erop rekenen dat dit beschikbaar blijft en blijft worden bijgewerkt, of is het een experimentje?

Van een versie in het Nederlandse profiel zou ik nóg blijer worden. Anders ben je als afnemer alsnog tegen twee verschillende standaarden aan het programmeren.

--
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.

Stefan de Konink

unread,
Jul 30, 2024, 6:05:03 AM7/30/24
to ope...@googlegroups.com
Op 7/30/24 om 11:59 schreef Thomas ten Cate:
> Dit is fijn, hartelijk dank! Kunnen we erop rekenen dat dit beschikbaar
> blijft en blijft worden bijgewerkt, of is het een experimentje?

Het doel is bijwerken (kan in principe geautomatiseerd) maar het is ook
een experiment.


> Van een versie in het Nederlandse profiel zou ik nóg blijer worden.
> Anders ben je als afnemer alsnog tegen twee verschillende standaarden
> aan het programmeren.

Dan moet je me even helpen bij een volgende BISON architectuur
vergadering. Want we hebben iets nodig om o.a. vleugeltreinen te
modelleren en de actuele reisinformatie aan elkaar te knopen.

Theoretisch kan exporteren in het Nederlands profiel (ook al), maar dan
zou je wel dubbele ritten krijgen met als doel dat een reisplanner het
doet. Het leidt dan natuurlijk (ook) tot dubbele aankomsttijden als je
een DRIS zou maken. Dus het moeten bijvoorbeeld trainBlocks of
journeyParts worden.

--
Stefan

OpenPGP_0xDA0A21EE7E3D2959.asc
OpenPGP_signature.asc

Thomas ten Cate

unread,
Jul 30, 2024, 6:27:56 AM7/30/24
to ope...@googlegroups.com
Ha, vleugeltreinen, daar heb ik in onze eigen modellering ook hoofdpijn van. Ik vrees dat ik er nog niet diep genoeg in zit (ben net gisteren serieus begonnen) om zelf aan TMI9 te kunnen bijdragen. TMI staat tenslotte ook voor Too Much Information. Maar als er in de volledige NeTEx-standaard een oplossing voor vleugeltreinen is, dan komt het vast goed.

Is het eigenlijk de bedoeling dat NS op termijn ook zelf NeTEx gaat leveren?

--
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.

Stefan de Konink

unread,
Jul 30, 2024, 7:13:21 AM7/30/24
to ope...@googlegroups.com
Op 7/30/24 om 12:27 schreef Thomas ten Cate:
> Ha, vleugeltreinen, daar heb ik in onze eigen modellering ook hoofdpijn
> van. Ik vrees dat ik er nog niet diep genoeg in zit (ben net gisteren
> serieus begonnen) om zelf aan TMI9 te kunnen bijdragen. TMI staat
> tenslotte ook voor Too Much Information. Maar als er in de volledige
> NeTEx-standaard een oplossing voor vleugeltreinen is, dan komt het vast
> goed.

Moet er natuurlijk wel een vraag zijn...


> Is het eigenlijk de bedoeling dat NS op termijn ook zelf NeTEx gaat leveren?

Uit de wandelgangen heb ik vernomen dat alle rail georiënteerde
standaarden uit TAP-TSI gaan en vervangen worden door NeTEx en SIRI. Dus
vanuit regelgeving wel.

Daarnaast is er een subsidietraject waar alle vervoerders mee bezig
zijn, ook NS, om NeTEx en SIRI te gaan doen.

--
Stefan

OpenPGP_0xDA0A21EE7E3D2959.asc
OpenPGP_signature.asc
Reply all
Reply to author
Forward
0 new messages