JourneyWaitTime.java (trip and stop specific wait time) is not really used or taken into account

[bufemc]

While WaitTime.java - using ORT_HZTF.x10 - seems to be fully implemented and used, JourneyWaitTime.java - using REC_FRT_HZT.x10 - is implemented to grab all the data, but is not really used.

To be more accurate: the only thing used there are the setters, but the getters are never used, and so the waiting time at a specific stop for a specific journey is never taken into account.

[bufemc]

Meanwhile solved it by myself. In short: in DAO you have also to collect the JourneyWaitTime "beans" into e.g. a list.. Then you split it by journey like it is done with Line mapped to RouteSequence. Then in the code where the WaitingTime is added, afterwards you also add the JourneyWaitTime (but ensure before that it matches the journey and the stop).

[bufemc]

Meanwhile I modified much more and improved it to my needs, check out the dev branch here: https://github.com/bufemc/onebusaway-vdv-modules/tree/dev

**Modifications (newest added at the end)**

Fixed: can handle also longitudes like 9.1234 now (previously had to be 09.1234)

Changed: model/EStopType.java can also handle stop_type >= 3 now, but will just return new type SKIP, as these are not relevant for GTFS (was meanwhile solved in original repository as well, so changes reverted here):

  "Bezeichner des funktionalen Typs eines Ortes <Ortstyp>
  1: Haltepunkt
  2: Betriebshofpunkt
  3: Ortsmarke
  4: LSA-Punkt
  5: Routenzwischenpunkt
  6: Betriebspunkt
  7: Grenzpunkt
Changed: model/Stop.java allows ORT_NAME to be empty now: @CsvField(name = "ORT_NAME", optional = true)

Changed: getStopTimesForJourney will skip entry if stop is null

Changed: in main method locale forced to be US, to prevent coordinates are exported like "50,48","9,78" (that happens e.g. in Germany)

Changed: coordinates with 0.0/0.0 are skipped for stops.txt AND stop_times.txt

Changed: first coordinate is reference coordinate. If later coordinates from vdv452 are implausible (see refMaxThreshold) we swap lon and lat. This was needed due to swapped coordinates in the input data for "region", especially for an agency.

Changed: only relevant stops (ONR_TYP_NR=1) are exported to stops.txt and stop_times.txt (that means other stops like depots (ONR_TYP_NR=2), border points etc. are not exported)

Added: if available, zone_id (can also contain an id for a so called Wabe) is exported to stops.txt now, too

Changed: Allow also illegal value "0" for lon/lat in REC_ORT.X10. Issue was raised for new data from agency an agency on 6th Sept 2017. Syntactially it is wrong (should be at least "00000000"), but would stop parsing and generating GTFS otherwise, and happens only for irrelevant data (ONR_TYP_NR>=2).

Changed: If there is no travel time on a trip at all (so say, first departure time is same as last departure) the trip is not saved to trips.txt and its stops is not saved to stop_times.txt. Reason were the trips for an agency in "region" with sometimes just 2 stops with same timing, and one even was the virtual bus arrival stop 510099 at the Hbf/ROB.

Changed: We don't count nor add stops with ONR_TYP_NR != 1 (e.g. 2 is a depot). If in the end the trip has 1 stop only, the trip is not saved to trips.txt and its stops is not saved to stop_times.txt.

Added: iff available, will retrieve the headsign via LID_VERLAUF.x10 (RouteSequence.java) and via REC_ZNR.x10 (Destination.java) to set it for trips.txt in GTFS. In case of "region": iff there is a ZNR_NR (aka "destination number id") != 0 set in LID_VERLAUF, it seems to be set for first stop only, while all following stops of this line ZNR_NR is 0 ("Bezeichner der Zielanzeige . Die ZNR_NR 0 wird verwendet, um das Display zu löschen" aka: if following the standard, that would mean we have to remove the headsign?). For REC_ZNR.x10 and the column "HECKANZEIGETEXT" see attached file doc/VDV_0105.pdf or http://open.sasabz.it/files/VDV_0105.pdf at section 6.2.12 REC_ZNR.

Added: by -preferRefName you can choose now if you prefer to use column ORT_REF_ORT_NAME instead of ORT_NAME in REC_ORT.x10 to build the stop_name for GTFS.

Added: as for an agency we found trips with headsign "Leerfahrt" we found out that there are 4 trip types ("Fahrtarten"), and these ones using ZNR_NR 985 for "Leerfahrt" were mainly using trip type 3 or 4. So in conversion process we now only allow trip type 1 ("Normalfahrt"), while skipping others. FAHRTART_NR - these are the offical values and meanings:

1: Normalfahrt
2: Betriebshofausfahrt
3: Betriebshofeinfahrt
4: Zufahrt
Added: While WaitTime.java - using ORT_HZTF.x10 - seems to be fully implemented and used, JourneyWaitTime.java - using REC_FRT_HZT.x10 - is implemented to grab all the data, but is not really used. Code has been extended to utilize JourneyWaitTime, too. To do so, it will first store the data in a list, split it up per journey/trip id, then add the waiting time in getStopTimesForJourney if there is one for this specific journey/trip and stop. See ADD_JWT in console output.

Added: parsing of optional column LEISTUNGSART_NR in REC_FRT.x10, which is defined in MENGE_LEISTUNGSART.x10

Changed: DegreesMinutesSecondsFieldMappingFactory.java can also handle 'illegal' coordinate "1/1" now, which is like 0/0 above in the ocean, so we flag this as a no-coordinate. Happens only for (regarding ONR_TYP) uninteresting stops anyway.