Page Comparison

"Delivery pattern"

• Subscription, Direct delivery

• ServiceDelivery hvert 10. sekund

• ca 100 meldinger hver gang, (500/min)

• ca 40 er uendret (150/min)

• ca 4 MB per delivery

• NSR-id'er på stopp

Feil og mangler

• Ingen NeTEx-id'er (tilsynelatende, men stemmer ikke med plandata)

• Noen få feil i tider (ankomst før avgang fra forrige stopp)

• Alle stopp sendes som "EstimatedCalls" - dvs. ingen "RecordedCalls" for passerte stopp

• Ingen tidssoner 

• Enkelte "feil" i estimater - bussen må kjøre >300 km/t for å rekke frem...

Skrudd av på grunn av mye feil-tagging som førte til at meldinger også ble inkludert på andre operatørers avganger.

"Delivery pattern"

• Subscription, Direct delivery

• ServiceDelivery ca hvert 15./20. sek

• ca 100 meldinger hver gang, (500/min)

Feil og mangler

• Noen få feil i tider (ankomst før avgang fra forrige stopp)

• Enkelte "feil" i estimater - bussen må kjøre >300 km/t for å rekke frem...

"Delivery pattern"

• Subscription, Direct delivery

• Ca. hvert 10. sekund

• à 200 meldinger (1100/min)

Feil og mangler

• Ingen NSR/NeTEx-id'er

• Ugyldig XML i hht. SIRI schema

• Sender også "alle" tidligere og påfølgende stopp for en del avganger

• Sender data som er utgått (dvs. "ValidUntilTime" er passert)

• Sender meldinger som ikke er endret siden forrige leveranse

"Delivery pattern"

• Subscription, Direct delivery

Feil og mangler

• Ingen NSR/NeTEx-id'er

• Ugyldig XML i hht. SIRI schema

• Meldinger hovedsaklig tagget på stopp - medfører avviksmeldinger inkluderes på feil avganger

"Delivery pattern"

• Polling

• Neste døgnet

• Request hvert minutt

• ca 1100 meldinger hver gang, 95 godstog

• 17 MB

• NB: Ny løsning på vei

Feil og mangler

• Ingen NSR/NeTEx-id'er

• Noen feil i tider (ankomst før avgang fra forrige stopp, avgang før ankomst)

• Subscription fungerer ikke

"Delivery pattern"

• Subscription, Direct delivery

• ServiceDelivery med én og én avgang

• ca 1000-2500 meldinger per min

Feil og mangler

• Forsinkelser for passerte stopp blir nullstilt når stopp er passert - dvs. faktisk passeringstid settes alltid lik planlagt tid for tidligere stopp. Gjør historiske data verdiløse.

"Delivery pattern"

• Subscription, Direct delivery

• ServiceDelivery med én og én avgang

• ca 250 / min

Feil og mangler

• Ingen NeTEx/NSR-id'er

• Kun "SIS"-busser (~3000 avganger i ET, ~300 i VM)

"Delivery pattern"

• Subscription, Direct delivery

Feil og mangler

• Enkelte meldinger tagges av og til for bredt, ellers ingen feil

"Delivery pattern"

• Subscription, Direct delivery

• ServiceDelivery hvert 10. sekund

• ca 50 meldinger hver gang, (150/min)

• ca 1.2 MB per delivery

Feil og mangler

• Ingen NSR/NeTEx-id'er

• Noen få feil i tider (ankomst før avgang fra forrige stopp)

"Delivery pattern"

• Subscription, Direct delivery

• ServiceDelivery hvert 5. sekund

• ca. 30 meldinger per gang

Feil og mangler

• Ingen NeTEx/NSR-id'er

• Subscription slutter å levere data etter ca 5 min - blir restartet og virker i nye 5 minutter

• Alle meldinger er gyldige til evig tid (dvs. år 9999)

"Delivery pattern"

• Subscription, Direct delivery

Feil og mangler

• Ingen NeTEx/NSR-id'er

• Meldinger tagges ofte for bredt

"Delivery pattern"

• Subscription, Direct delivery

• ServiceDelivery hvert 10. sekund

• ca 10 meldinger hver gang, (100/min)

Feil og mangler

• Ingen NSR/NeTEx-id'er

• Stopp er basert på "StopPlace"-id + plattform

• Noen feil i tider (ankomst før avgang fra forrige stopp, avgang før ankomst)

• Enkelte "feil" i estimater - må kjøre >300 km/t for å rekke frem...

"Delivery pattern"

(3 separate VM-feeds inn til Entur)

1. Halden:
   - Subscription, Direct delivery
   - ServiceDelivery ved hver oppdatering
   - ca 40 meldinger/min

2. Indre Østfold
   - Subscription, Direct delivery
   - ServiceDelivery ved hver oppdatering

   - ca 40 meldinger/min

3. Østfold forøvrig
   -Subscription, Direct delivery
   - Ca. hvert 10. sekund
   - à 50 meldinger (300/min)
   - Oppdatering ca hvert 10.sekund

Feil og mangler

1. Halden
   - Enkelte “Deadrun”-avganger

2. Indre Østfold
   - Ingen

3. Østfold forøvrig
   - Ingen NSR/NeTEx-id'er
   - Ugyldig XML i hht. SIRI schema
   - Sender også "alle" tidligere og påfølgende stopp for en del avganger
   - Sender data som er utgått (dvs. "ValidUntilTime" er passert)
   - Sender enkelte meldinger som ikke er endret siden forrige leveranse

"Delivery pattern"

• Subscription, Direct delivery

Feil og mangler

• Ingen NSR/NeTEx-id'er

• Meldinger (ofte) tagget for bredt

• Enkelte meldinger som ikke er tagget på noe

"Delivery pattern"

• Subscription, Direct delivery

• ServiceDelivery hvert 10. sekund

• ca 25 meldinger hver gang, (100/min)

Feil og mangler

• Noen feil i tider (ankomst før avgang fra forrige stopp, avgang før ankomst)

• Enkelte "feil" i estimater - bussen må kjøre >300 km/t for å rekke frem...

"Delivery pattern"

• Subscription, Direct delivery

• Ca. hvert 10. sekund

• à 150 meldinger (800/min)

• VKT og TEL er i samme feed

Feil og mangler

• Ingen NSR/NeTEx-id'er

• Ugyldig XML i hht. SIRI schema

• Sender også "alle" tidligere og påfølgende stopp for en del avganger

• Sender data som er utgått (dvs. "ValidUntilTime" er passert)

• Sender enkelte meldinger som ikke er endret siden forrige leveranse

"Delivery pattern"

• Subscription, Direct delivery

• ServiceDelivery hvert 10. sekund

• ca 40 meldinger hver gang, (250/min)

• 1 er uendret (5/min)

• ca 2.3 MB per delivery

• Ingen NSR/NeTEx-id'er

• Stopp er basert på "StopPlace"-id + plattform, men sender ikke plattform

• Noen feil i tider (ankomst før avgang fra forrige stopp, avgang før ankomst)

• i bruk?

"Delivery pattern"

• Subscription, Direct delivery

• ServiceDelivery "kontinuerlig"

• 700/min

• ca 450/min er uendret siden forrige oppdatering

Feil og mangler

• Ustabil subscription - dvs. vi slutter ofte å motta data

• Noen feil i tider (ankomst før avgang fra forrige stopp, avgang før ankomst)

"Delivery pattern"

• For tiden ikke fungerende - Hogia undersøker

Skrudd av siden SX-feeden ikke er frittstående, men krever ET-data for å kunne koble meldinger til riktig avgang.

"Delivery pattern"

• Subscription, Direct delivery

• ServiceDelivery hvert 10. sekund

• ca 40 meldinger hver gang, (250/min)

• 10 er uendret (60/min)

Feil og mangler

• Ingen NSR/NeTEx-id'er

• Ingen tidssoner

• Noen feil i tider (ankomst før avgang fra forrige stopp, avgang før ankomst)

"Delivery pattern"

• Subscription, Direct delivery

Feil og mangler

• For tiden ingen data å se på...

"Delivery pattern"

• Subscription, Direct delivery

• ServiceDelivery hvert 10. sekund

• ca 50 meldinger hver gang, (550/min)

• 15 er uendret (175/min)

• ca 1.5 MB per delivery

Feil og mangler

• Ingen NSR/NeTEx-id'er

  • Buss-feed bruker interne id’er

  • Bybanen-feed bruker et internt løpenummer

• Noen feil i tider (ankomst før avgang fra forrige stopp)

"Delivery pattern"

• Subscription, Direct delivery

• "Kontinuerlig" strøm

• ca. 3000/min

• Hvert kjøretøy oppdateres ca hvert 5. sekund

Feil og mangler

• Ingen NSR/NeTEx-id'er

• Skyss' interne, kjente id'er er prefixet med "NSR:Quay:" for å ikke bli flagget i SIRI-validator. Resultatet er at id'ene ikke kan brukes til noe.

"Delivery pattern"

• Subscription, Direct delivery

Feil og mangler

• Ingen NSR/NeTEx-id'er

• Meldinger tagges for bredt slik at de også kommer på andre avganger enn det som er intensjonen - også andre operatørers avganger.

"Delivery pattern"

• Subscription, Direct delivery

• ServiceDelivery hvert 10. sekund

• ca 100 meldinger hver gang, (500/min)

• 50 er uendret (150/min)

Feil og mangler

• Ingen NSR/NeTEx-id'er

• Noen feil i tider (ankomst før avgang fra forrige stopp)

• Enkelte "feil" i estimater - må kjøre >300 km/t for å rekke frem...

"Delivery pattern"

• Subscription, Direct delivery

• Hvert 5. sekund

• à ca 200 meldinger (ca 2000 / min)

• 200/min er uendret

Feil og mangler

• Ingen NSR/NeTEx-id'er

• Alle meldinger er gyldige til evig tid (dvs. år 9999)

• Enkelte meldinger sendes uten VehicleLocation, enkelte med posisjon (0, 0)

"Delivery pattern"

• Subscription, Direct delivery

Feil og mangler

• Meldinger tagges for bredt slik at de også kommer på andre avganger enn det som er intensjonen

"Delivery pattern"

• Subscription, Direct delivery

• ServiceDelivery "kontinuerlig"

• ca 100/minutt

• ca 30/min er uendret

Feil og mangler

• Noen få tilfeller av "ankomst før avgang fra forrige stopp" - ellers ihht. profil

"Delivery pattern"

• Subscription, Direct delivery

• ca 60/min

• Oppdateringer hvert 10-30 sekund (avhengig av buss)

Feil og mangler

• Ingen oppdaget

"Delivery pattern"

• Subscription, Direct delivery

Feil og mangler

• Ingen oppdaget

"Delivery pattern"

• Subscription, Direct delivery

• Brukes til "buss-for-tog"

Feil og mangler

• Avganger sendes inn lenge før de skal kjøre - burde i en del tilfeller blitt sendt som plandata i stedet.

• Planlagte BFT-avganger sendes inn med datastrukturen til ikke-planlagte (dvs. ExtraJourneys). Dataene blir derfor ikke brukt.

"Delivery pattern"

• Subscription, Direct delivery

• ca 10-12/min

• Oppdatering hvert 30. sekund

Feil og mangler

"Delivery pattern"

• Subscription, Direct delivery

Feil og mangler

• Feil i NeTEx-id (dvs. ServiceJourneyId som refereres i SX-data finnes ikke i plandata). Kan det ha kommet nytt datasett hvor SJ-id er endret, men at sanntidssystemet ikke har blitt oppdatert med samme data?

"Delivery pattern"

• Subscription, Direct delivery

• ServiceDelivery hvert 10. sekund

• ca 10 meldinger hver gang, (100/min)

Feil og mangler

• Ingen NeTEx-id'er (tilsynelatende, men stemmer ikke med plandata)

• Enkelte "feil" i estimater - må kjøre >300 km/t for å rekke frem...

"Delivery pattern"

• Subscription, Direct delivery

• ServiceDelivery hvert 10. sekund

• ca 10-15 meldinger hver gang, (100/min)

• de aller fleste meldinger er uendret (relatert til utdaterte data?)

Feil og mangler

• Ingen NeTEx-id'er (tilsynelatende, men stemmer ikke med plandata)

• Ugyldig XML i hht. SIRI schema

• Sender også "alle" tidligere og påfølgende stopp for de fleste avganger

• Sender data som er utgått (dvs. "ValidUntilTime" er passert)

• Sender mange meldinger som ikke er endret siden forrige leveranse

• Mangler GPS-posisjonsdata for de aller fleste (alle?)

"Delivery pattern"

• Subscription, Direct delivery

• ServiceDelivery hvert 10. sekund

• ca 250-300 meldinger hver gang (ca 300/min)

Feil og mangler

• Enkelte "feil" i estimater - må kjøre >300 km/t for å rekke frem. (antagelig pga. minutt-oppløsning i plandata, og flere stopp innenfor samme minutt).

"Delivery pattern"

• Subscription, Direct delivery

• ServiceDelivery med alle kjøretøy ca hvert 2. sekund

• ca 8-10.000 per min

"Delivery pattern"

• Subscription, Direct delivery

Feil og mangler

• Ingen oppdaget

"Delivery pattern"

• Subscription, Direct delivery

• 1 melding per ServiceDelivery

• ca 1/min

Feil og mangler

• Ugyldig XML i hht. SIRI schema (noen få av leveransene)

• Noen feil i tider (ankomst før avgang fra forrige stopp)

• Enkelte "feil" i estimater - må kjøre >300 km/t for å rekke frem...

• Enkelte tilfeller av samme stopp 2 ganger (som RecordedCall og EstimatedCall)

• "Mangler" ET-data for en del avganger (23 avganger i ET vs. 120 i VM).

"Delivery pattern"

• Subscription, Direct delivery

• Én og én melding

• 300/min

Feil og mangler

• Mottar SIRI VM-meldinger for avganger vi ikke mottar SIRI ET for.

"Delivery pattern"

• Subscription, Direct delivery

• Kun buss-for-tog

Feil og mangler

• Har ikke funnet relevante data å se på

"Delivery pattern"

• Subscription, Direct delivery

• Én melding per "delivery"

Feil og mangler

• Ingen oppdaget