HSLdevcom / digitransit-ui

Digitransit UI ("Reittiopas.fi")
https://www.reittiopas.fi/
Other
242 stars 133 forks source link

Vehicles of different route types behave differently with realtime data (MQTT vehicle positions) #3210

Open BodoMinea opened 4 years ago

BodoMinea commented 4 years ago

I have observed on my own test Digitransit instance that buses are shown both on the linear trip timetable and on the actual map as markers, where trains are not shown on the route map even when they have position data, but they are shown on the timetable „progress”. chrome_Gbq1QDXVQr chrome_LdEx9hnJ5X These feeds are configured identically: trip updates through OTP router config and high frequency real-time positioning with MQTT and the related configuration for subscribing in realtimeUtils.js. The data is getting to the browser, the websocket is working, as that is the data source for the linear view.

I'm not sure if that was a fluke or what, but upon zooming on the map with no route selected, the position of a train seemed to appear, with the route short text on it just briefly, and it was gone the second after.

Could someone please point me into the right direction as what configurations are to be done and where in order to make these function the same?

optionsome commented 4 years ago

Perhaps the vehicles get filtered out in https://github.com/HSLdevcom/digitransit-ui/blob/master/app/component/map/VehicleMarkerContainer.js#L85 for some reason. Is the data you are using in GTFS RT format? Have you tried debugging https://github.com/HSLdevcom/digitransit-ui/blob/master/app/util/gtfsRtParser.js to see if the bus and train messages somehow differ from each other?

BodoMinea commented 4 years ago

I have debugged what I could get my head around on those two files already. They don´t seem to filter the vehicles out. The data I am using is GTFS-RT vehicle positions published to MQTT. The original feed is outputted by the same producing software for all feeds (TheTransitClock) and also it is published to MQTT by the same script.

The MQTT messages are getting to the browser through websocket and are largely identical, so no subscription problem over here. Here are some sample messages that are getting through but behaving differently:

Bus - these appear on the map /gtfsrt/vp/TURSIB////18/0//18_60600_0_0_3/3122//SB 94 TSB/45;24/81/04/89/18/ /gtfsrt/vp/TRANSBUS////11/0//11_54685_0/BZ164//BZ85VJL/45;26/18/51/27/11/

Train - these do not appear on the map but appear in the linear trip progress view /gtfsrt/vp/TFC////7/0//15364/52479//029-030/45;26/33/25/47/TFC R/ /gtfsrt/vp/TFC////11/0//15164/30110//3230-3231/44;25/49/99/80/TFC R/

Any other tips you could share? The only notable thing that seems to differ to me is the route type (which is not referenced in any message but is in the static GTFS...).

BodoMinea commented 4 years ago

I think I got to seeing some relevant error messages in the console... These only happen for the train routes and they show up after a while or after resizing / refreshing:

checkPropTypes.js:20 Warning: Failed prop type: Invalid prop children of type object supplied to FormattedMessage, expected function in FormattedMessage (created by withProps(FormattedMessage))

checkPropTypes.js:20 Warning: Failed prop type: The prop pattern is marked as required in RouteMapContainer, but its value is null in RouteMapContainer (at withBreakpoint.js:99)

checkPropTypes.js:20 Warning: Failed prop type: The prop pattern is marked as required in PatternStopsContainer, but its value is null in PatternStopsContainer (at withBreakpoint.js:99)

I'm trying to study those files but not seeing anything obvious that could be wrong.

optionsome commented 4 years ago

We don't have any GTFS RT format vehicle positions feeds that would provide train data so there might be some bug related to it but I have no clear vision to why it would be different. Have you tried enabling showAllBusses: true and/or showVehiclesOnStopPage: true in your config so you could see the vehicles in front page or in stop pages?