search

openTdataCH / ojp-sdk

Meta OJP SDK repo
MIT License
4 stars 0 forks source link

TR LegIntermediate doesnt conform to XSD schema #42

Open vasile opened 1 month ago

vasile commented 1 month ago

Given any TR Bern - Zürich or with Params/IncludeIntermediateStops = True

This LegIntermediate node is returned and doesnt conform with the schema https://vdvde.github.io/OJP/develop/index.html#LegIntermediateStructure

  <LegIntermediate>
      <siri:StopPointRef>132</siri:StopPointRef>
      <StopPointName>
          <Text xml:lang="de">Bahn-2000-Strecke</Text>
      </StopPointName>
      <Order>2</Order>
  </LegIntermediate>

Expected:

vasile commented 1 month ago

~The issue is labelled as blocker due to required ServiceArrival/ServiceDeparture in the TR model~ https://github.com/openTdataCH/ojp-ios/blob/main/Sources/OJP/Models/OJPv2%2BTrip.swift#L275-L276

But for now we can make these optional until backend fix is present

r3to commented 1 week ago

@TO-mdv is this a complex bug to be fixed? If not, it would be cool to prfioritize this, so we don't have to implement workarounds.

TO-mdv commented 4 days ago

@r3to I cannot reproduce this issue. Example TR S26 between Zürich-Bern delivers ServiceArrival and ServiceDeparture :

<LegIntermediate>
    <siri:StopPointRef>ch:1:sloid:2113:3:5</siri:StopPointRef>
    <StopPointName>
        <Text xml:lang="de">Aarau</Text>
    </StopPointName>
    <NameSuffix>
        <Text xml:lang="de">NO_DATA</Text>
    </NameSuffix>
    <PlannedQuay>
        <Text xml:lang="de">5</Text>
    </PlannedQuay>
    <EstimatedQuay>
        <Text xml:lang="de">5</Text>
    </EstimatedQuay>
    <ServiceArrival>
        <TimetabledTime>2024-07-01T07:07:00Z</TimetabledTime>
        <EstimatedTime>2024-07-01T07:07:00Z</EstimatedTime>
    </ServiceArrival>
    <ServiceDeparture>
        <TimetabledTime>2024-07-01T07:08:00Z</TimetabledTime>
        <EstimatedTime>2024-07-01T07:08:12Z</EstimatedTime>
    </ServiceDeparture>
    <Order>2</Order>
</LegIntermediate>
TO-mdv commented 4 days ago

Also the NoBoardingAtStop + NoAlightingAtStop are delivered, example Zürich - St Margrethen SG:

<LegIntermediate>
    <siri:StopPointRef>ch:1:sloid:6000:3:5</siri:StopPointRef>
    <StopPointName>
        <Text xml:lang="de">Winterthur</Text>
    </StopPointName>
    <NameSuffix>
        <Text xml:lang="de">NO_DATA</Text>
    </NameSuffix>
    <PlannedQuay>
        <Text xml:lang="de">5</Text>
    </PlannedQuay>
    <EstimatedQuay>
        <Text xml:lang="de">5</Text>
    </EstimatedQuay>
    <ServiceArrival>
        <TimetabledTime>2024-12-13T12:57:00Z</TimetabledTime>
    </ServiceArrival>
    <ServiceDeparture>
        <TimetabledTime>2024-12-13T12:58:00Z</TimetabledTime>
    </ServiceDeparture>
    <Order>3</Order>
    <NoAlightingAtStop>true</NoAlightingAtStop>
</LegIntermediate>
r3to commented 4 days ago

@TO-mdv The "Aarau" example is from a connection with an actual stop.

What @vasile refered to, were connections like the IC8 where "Bahn-200-Strecke" is shown as LegIntermediate but without the other required elements. (Note: this snippet is from Prod, as the other environments are not reachable at the moment)

<LegIntermediate>
  <siri:StopPointRef>132</siri:StopPointRef>
  <StopPointName>
    <Text xml:lang="de">Bahn-2000-Strecke</Text>
  </StopPointName>
  <Order>2</Order>
</LegIntermediate>
TO-mdv commented 4 days ago

@r3to Ah perfect, now I've got the example. I will create a bug for this, hopefully it's a small issue, so we will fix it soon

TO-mdv commented 11 hours ago

Wir werden Durchfahrten als kurzfristige Lösung komplett aus der Antwort löschen. Hintergrund: wenn wir diese mit den An-/Abfahrtszeiten übernehmen, wir von der Echtzeit jedoch diese Durchfahrten nicht erhalten, werden diese immer als "Zusatzhalte" interpretiert. SH-3219 OJP2.0 TR Durchfahrtshaltestellen nicht ausgeben (Bahn-2000-Strecke)