1

Vejledning om brug af NeTEx

NeTEx er en teknisk standard i EU, som kan bruges til at beskrive rigtig mange aspekter af den kollektive trafik, lige fra den fysiske infrastruktur inklusive stoppesteder, køreplaner, chaufførplanlægning til information om billetpriser og zoner. Fordi modellen skal være fleksibel og kunne dække en lang række transporttekniske behov i Europa, giver modellen også mulighed for mange forskellige måder at modellere forskellige aspekter fra virkeligheden.

Til rejseplanlægning er der kun behov for en mindre del af det, der kan beskrives ved hjælp af NeTEx, og en "profil" definerer, hvilke dataelementer, der skal udstilles, og i hvilken form det skal ske. I Danmark er det besluttet at anvende den Europæiske minimumsprofil, European Passenger Information Profile (EPIP)1.

Sigtet med denne vejledning er at specificere hvilken information, der som minimum skal leveres, samt at beskrive nationale specifikationer til levering af data. De beskrevne regler skal bidrage til at sikre en ensartet og genkendelig struktur på tværs af virksomheder, som leverer transportydelser.

På Trafikstyrelsens hjemmeside findes et eksempel, som illustrerer hvordan data for en færgerute skal leveres i henhold til EPIP-formatet og nedenstående specifikationer.

2

Filer

Data i NeTEx-format er XML-filer, der passer nøjagtigt til det definerede skema. I Danmark anvendes EPIP med tilhørende XML-skema (link findes på Trafikstyrelsens hjemmeside https://www.trafikstyrelsen.dk/arbejdsomraader/kollektiv-trafik/statistik-og-data/krav-til-udstilling-af-data-til-rejseplanlaegning).

Der skal oprettes særskilte XML-filer for hver buslinje/færgerute, og disse leveres samlet til Dataudveksleren i en zip-fil.

3

Navngivning

Navngivning af filer skal opfylde følgende struktur:

[prefix]-[epip-version]_[landekode]_[dataleverandørkode]_[profile-type]_[public code]-[Nr. eller navn på linjen eller ruten]_[Oprettelsesdato]

Hvor;

[prefix]: Benyt ’NX-PI’

[epip-version]: Den gældende version af EPIP, på nuværende tidspunkt ‘01’

[landekode]: ISO landekode – for Danmark benyt ’DK’

[Dataleverandørkode]: Benyt ‘NAP’

[Profiltype]: Benyt ’LINE’

[public code]: Trafikstyrelsen har tildelt den enkelte dataleverandørs public code, som fremgår af oversigten ”Oversigt over dataleverandørers id og public code” (findes på https://www.trafikstyrelsen.dk/arbejdsomraader/kollektiv-trafik/statistik-og-data/krav-til-udstilling-afdata-til-rejseplanlaegning). Kontakt os for tildeling af disse, hvis din virksomhed eller kommune ikke findes på oversigten.

[Nr. eller navn på linjen eller ruten]: Nr. eller navn kan vælges frit.

[Oprettelsesdata]: Dato for oprettelse af filen (YYYYMMDD).

4

Brug af ID

Alle rammer og objekter i rammerne skal tildeles et ID, så det er muligt at referere til rammer og objekter andre steder.

ID’er skal have denne struktur:

DK::<ramme- eller objektnavn>:<public code>-<identifikator>

<public code>: Dataleverandørens public code, som fremgår af oversigten ”Oversigt over dataleverandørers id og public code”.

<identifikator>: Kan vælges frit, men skal være unik, hvis der er flere af samme objekt. F.eks. skal hvert stoppested have en unik identifikator.

5

Brug af version

Vi anbefaler, at dato anvendes som versionsnummer i formatet YYMMDD.

6

Opbygning af XML-filerne

XML-filerne skal altid indledes med følgende:

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>

UTF-8 er standardkodning for XML-dokumenter.

NeTEx-formatet er bygget op via en rammestruktur med kun ét roottag, Publication Delivery. I EPIP er det specificeret, at XML-filerne skal opbygget hierakisk jf. nedenstående figur.

 

Figur 1: Strukturen i EPIP-formatet

6.1

Beskrivelse af indhold i rodelement og rammer

I afsnittene nedenfor er opstillet tabeller, hvor det fremgår, hvad rod-elementet og de enkelte rammer mindst skal indeholde. Det tilhø-rende fileksempel illustrerer hvordan dette opstilles i en XML-fil.

Detaljerede krav til formater og beskrivelser af indholdet kan findes i EPIP.

 

6.2

Publication Delivery

Alt filens indhold samles under PublicationDelivery.

 

Tabel 1: Indhold i PublicationDelivery

Navn

Beskrivelse

PublicationTimestamp

Dato og tidspunkt for output.

Format: UTC

ParticipantRef

Angiver hvem der leverer data.

dataObjects

- CompositeFrame

Indeholder CompositeFrame og dennes indhold.

 

6.3

Composite Frame

Composite Frame bruges til at gruppere de underliggende rammer. Formålet med rammen er at gruppere en række rammer som alle har samme gyldighedsbetingelser og andet.

En Composite Frame der er i overensstemmelse med EU_PI_LINE_OF-FER, skal kun indeholde data for en enkelt linje.

 

Tabel 2: Indhold i Composite Frame

Navn

Beskrivelse

CompositeFrame

- Id

- version

Eksempel på id:

DK::CompositeFrame_EU_PI_LINE_OFFER:KON-KorsørNyborg"

ValidBetween

- FromDate  

- ToDate

 

 

Gyldighed for de data som leveres. Bemærk, at dette er den dominerende gyldighedsbetingelse. Angives der anden gyldighed på lavere niveauer, begrænses disse af Composite Frame.

Anvend følgende format: YYYY-MM-DDT tt.mm.ss

F.eks.: 2022-09-01T00:00:00

TypeOfFrameRef

- Ref

- versionRef

Refererer til den rammetype som benyttes.

ref = epip:EU_PI_LINE_OFFER

versionRef = 1.0

Codespaces

- codespace

- id

- Xmlns

- XmlnsUrl

 

 

id = epip_data

Xmlns = epd

XmlnsUrl = http://netex-cen.eu/epip_data

FrameDefaults

- DefaultCodespaceRef

- ref

- DefaultDataSourceRef

- ref

- DefaultLocale

- Timezone

- DefaultLanguage

- DefaultLocationSystem

 

 

ref = epip_data

ref = epip_data:DataSource:General

Timezone = Europe/Copenhagen

DefaultLanguage = da

DefaultLocationSystem = urn:ogc:def:crs:EPSG::4326

(Koordinater for stoppesteder skal leveres i WGS84.) 

frames

Indeholder de øvrige rammer og deres indhold.

6.4

Resource Frame

I Resource Frame defineres almindelige og generiske objekttyper, der kan benyttes på tværs af flere andre rammer. Resource Frame benyttes til at udveksle almindelige referencedata såsom operatører, tilstande, faciliteter mv.

 

Tabel 3: Indhold i Resource Frame

Navn

Beskrivelse

ResourceFrame

- id

- version

Eksempel på id:

DK::ResourceFrame_EU_PI_COMMON:KON-KorsørNyborg

TypeOfFrameRef

- ref

- versionRef

Refererer til rammetypen.

ref = epip:EU_PI_COMMON

VersionRef = 1.0

dataSources

- DataSource

- id

- version

- Name

 

 

id = "epip_data:DataSource:General"

 

Name = DK 

organisations

- Authority

- id

- version

- PublicCode

- Name

- ContactDetails

- Email

- OrganisationType

Indeholder oplysninger om dataleverandøren (authority).

Såfremt der er forskel på dataleverandøren og operatøren skal det fremgå.

Trafikstyrelsen har tildelt de enkelte virksomheders id og public code, som fremgår af oversigten ”Oversigt over dataleverandørers id og public code” (findes på https://www.trafikstyrelsen.dk/arbejdsomraader/kol-lektiv-trafik/statistik-og-data/krav-til-udstilling-af-data-til-rejseplanlaegning). Kontakt os for tildeling af disse, hvis din virksomhed eller kommune ikke findes på oversigten.

 

6.5

Service Calendar Frame

Service Calendar Frame benyttes til at definere alle objekter som relaterer til kalendere og typer af dage. Her defineres dagstyper (f.eks. hverdage, weekender mv.).

Da flere komponenter genbruges på tværs af datasættet, som f.eks. dagstyper og driftsperioder, anbefales det at definere disse direkte i Service Calendar Frame.

 

Tabel 4: Indhold i ServiceCalendarFrame

Navn

Beskrivelse

ServiceCalendarFrame

- id

- version

Eksempel på id:

DK::ServiceCalendarFrame_EU_PI_CALENDAR: KON-KorsørNyborg

TypeOfFrameref

- ref

- versionRef

Refererer til rammetypen.

ref = ”epip:EU_PI_CALENDAR”

versionRef = ”1.0”

ServiceCalendar

- id

- version

Indeholder dagstyper, driftsperioder og forbindelser.

 

 

dayTypes

- DayType

- id

- version

 

 

 

 

 

 

Dagstyper efter køreplan/sejlplan, f.eks. arbejdsdag, skoleferie, hverdag eller weekend etc. Det er op til den enkelte dataleverandør at definere de enkelte dagstyper. Hvis linjen/ruten altid kører/sejler på alle dage, kan man nøjes med at definere en dagstype.

I Timetable frame kan en afgang på et bestemt klokkeslæt tildeles en af de predefinerede dagstyper, så den f.eks. opererer alle dage eller kun i weekender.

Nedenstående er et eksempel på hvordan dagstyper kan defineres.

37 = fredag til søndag

38 = mandag til torsdag

Nummereringen defineres af dataleverandøren.

operatingPeriods

- UicOperatingPeriod

- id

- version

- FromDate

- ToDate

- ValiddayBits

 

 

 

 

 

operatingPeriods Specificerer en driftsperiode. Perioden skal defineres inden for den tidligere definerede fra/til dato (under CompositeFrame).

Såfremt der er defineret flere dagstyper, skal der tilknyttes en driftsperiode til hver enkelt dagstype. Der kan med fordel anvendes samme ID-nummer som under dagstyper, da det vil lette den efterfølgende sammenkobling af de korrekte dagstyper og driftsperioder.

Driftsperioderne skal angives som UicOperatingPeriod hvor til/fra dato skal angives samt en binær talkode. Den binære talkode skal angives som en dag i den angivne periode.

Har man f.eks. angivet en dagstype til at være weekender (fredag til søndag), vil ValidDayBits for perioden mandag d. 5. september til søndag d. 11. september 2022 være

Validdaybit = 0000111

dayTypeAssignments

- DayTypeAssignment

- id

- order

- version

- OperatingPeriodRef

- ref

- version

- DayTypeRef

- ref

- version

Kobler de specifikke dagstyper til specifikke driftsdage. Den samme dagstype kan tildeles flere driftsdage og omvendt.

Tildelingen af dagstyer defineres på hver enkelt dags-type som er defineret under daytypes.

 

 

 

 

 

 

 

 

6.6

Service Frame

Service Frame bruges til at udveksle den grundlæggende beskrivelse af et transportnetværk.

 

Tabel 5: Indhold i ServiceFrame

Navn

Beskrivelse

ServiceFrame

- id

- version

Eksempel på id:

DK::ServiceFrame_EU_PI_NETWORK: KON-KorsørNy-borg

TypeOfFrameRef

- ref

- versionRef

Refererer til rammetypen.

ref ="epip:EU_PI_NETWORK"

versionRef = "1.0"

lines

- Line

- id

- version

- Name

- Transportmode

- AuthorityRef

- ref

- version

 

Her angives nummer/navnet på linjen/ruten.

 

 

 

Transportmode sættes til ”bus” for en fjernbuslinje og ”water” for en færgerute.  

 

 

 

 

scheduledStopPoints

- ScheduledStopPoint

- id

- version

- Name

- Location

- Longitude

- Latitude

Beskriver de stoppesteder/færgelejer der indgår på den aktuelle linje/rute. Bemærk at der også senere skal angives navn og koordinater på stoppesteder/færgelejer i Site Frame. Her kan der anvendes samme navn og placering.

 

 

 

 

 

ServiceLinks

- ServiceLink

- id

- version

- FromPointRef

- ref

- version

- ToPointRef

- ref

- version

Beskriver forbindelsen mellem stoppesteder/færgelejer.

 

 

 

 

 

 

 

 

 

stopAssignments

- PassengerStopAssignment

- id

- order

- version

- ScheduledStopPointRef

- ref

- version

- StopPlaceRef

- ref

- version

Forbinder ScheduledStopPoint’s med de stoppesteder/havne der senere angives med navn og koordinater i Site Frame.

 

 

 

 

 

 

 

 

 

journeyPatterns

- ServiceJourneyPattern

- id

- version

- Routeview

- id

- Lineref

- Ref

- Version

- PointsInSequence

- StopPointInJourneyPattern

- Id

- order

- version

- ScheduleStopPointRef

- ref

- version

 

- noticeAssignments

- NoticeAssignment

- Id

- version

- Notice

- id

- version

- Text

Forbinder buslinje/sejlrute med stoppesteder/havne og information om kørestolsadgang angives.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Såfremt der er adgang med kørestol på den pågældende bus eller færge, skal det fremgå under noticeAssignments.

Følgende tekst kan benyttes:

Adgang mulig med kørestol

 

 

 

 

6.7

Site Frame

Site Frame bruges til at udveksle den grundlæggende beskrivelse af stoppesteder.

 

Tabel 6: Indhold i Site Frame

Navn

Beskrivelse

SiteFrame

- id

- version

Eksempel på id:

DK::SiteFrame_EU_PI_STOP: KON_KorsørNyborg

 

TypeOfFrameref

- Ref

- VersionRef

ref = ”epip:EU_PI:STOP”

stopPlaces

- StopPlace

- id

- version

- Name

- Centroid

- Location

- Longitude

- Latitude

- StopPlaceType

 

 

 

Name = Navn på stoppested/havn

 

Longitude = Længdegrad på stoppestedet

Latitude =Breddegrad på stoppestedet

 

StopPlaceType sættes til ”onstreetBus” for en fjernbuslinje og ” ferryPort” for en færgerute. 

6.8

Timetable Frame

Det er i Timetable Frame at den egentlig køre- eller sejlplan angives.

 

Tabel 7: Indhold i TimetableFrame

Navn

Beskrivelse

TimetableFrame

- id

- version

Eksempel på id:

DK::TimetableFrame_EU_PI_TIMETABLE:KON_KorsørNyborg

TypeOfFrameref

- ref

- versionRef

ref = "epip:EU_PI_TIMETABLE"

vehicleJourneys

- ServiceJourney

- id

- version

- dayTypes

- daytyperef

- ref

- version

- ServiceJourneyPatternRef

- ref

- version

- passingTimes

- TimetablePassingTime

- id

- version

- StopPointInJourneyPat-ternRef

- ref

- version

- DepartureTime

- ArrivalTime

- ArrivalDayOffset

Definerer de enkelte afgange.

 

 

 

 

Daytype skal referere til en af de dagstyper, som er defineret under ServiceCalenderFrame.

 

 

 

 

 

 

 

 

 

 

 

 

ArrivalDayOffset skal kun benyttes, hvis en afgang afsluttes efter midnat (turen foregår i princippet på to forskellige datoer før/efter midnat).