BC navita provider: no PhysicalMode "NA"

[anjandev]

[anjandev]

I investigated this issue. Turns out that when the route includes the skytrain (the overhead subway in vancouver) Navitia returns the "NA" physical mode.

https://api.navitia.io/v1/coverage/ca-bc/journeys?from=poi%3Aosm%3Anode%3A384252960&to=poi%3Aosm%3Away%3A102254132&

[schildbach]

What does "NA" stand for? Maybe "not available" or "not applicable"? If so, then I'd vote for removing the enum value entirely and use "null" instead.

[anjandev]

@schildbach in this case, vancouver's skytrain was placed as NA. Should I put it as null? Would that not just remove the physical mode from apps? Ie. When a route requires the skytrain it's just a blank?

[schildbach]

Actually I'm not so sure any more. PhysicalMode is used within AbstractNavitiaProvider only, so apps (= users of the library) won't care about it.

@aelkhour once introduced the enum in commit 9f2b3b5, maybe he want to add his view to the discussion?

[anjandev]

@schildbach I sent an email to @aelkhour and I have not gotten a response. It has been a week.

What is the purpose of the physical_mode. Like what is it used for? Can we change it to Null?

[schildbach]

@prhod This issue about "NA" PhysicalMode in the British Columbia dataset is very similar to #236. What does NA stand for? Is it perhaps an error in the dataset?

[schildbach]

I should mention that according to http://doc.navitia.io/#public-transport-objects NA is not valid.

[grote]

I think ideally Navitia's data team fixes this at their side and sets the proper physical mode. There should be a QA step in the publishing pipeline that ensures all physical modes are valid.

[schildbach]

@grote Agreed.

[anjandev]

@grote @schildbach yes, a QA process would be nice because routes with the skytrain were working before and they just stopped working...

[grote]

If there's not answer from @prhod, you can also mail them https://groups.google.com/forum/#!forum/navitia It is a separate organization.

[prhod]

Hello @grote @schildbach, sorry for the delay of the response !
The purpose of the physical_mode is to provide a fixed list modes in Navitia (or as fixed as possible).
On the other hand, the commercial_mode is not fixed, and can take any value.

We are working on a new data pipeline that will allow us to detect more easily those inconsistencies in physical_modes. Hopefully, you shouldn't have those errors anymore starting mid-2019. In the mean time, please notify us (using the GoogleGroup if possible).

I'll take a look at this NA value and see if we can fix it quickly.
Best regards

[prhod]

We've just fixed the issue and checked with TransportR.
Best

[schildbach]

Thanks a lot for your help.

[schildbach]

@prhod Region Finland still has NA PhysicalModes. Can you fix it there, too?

[prhod]

@schildbach thanks for the notification, I've warned our Data team. It should be fixed in a few days (sorry for the delay).

[prhod]

@schildbach Region Finland has been fixed. We may have again this issue when GTFS has new route_types. We actually need to fix them manually each time until our new pipeline is in charge. It will take some time to cover all the coverages.

[ialokim]

@prhod We've spot another one in the Region Portugal. Would be great if you could look after it, too.

[prhod]

@ialokim thanks for the notice, the issue will be solved ASAP

[prhod]

@ialokim Portugal has been fixed. We are migrating the coverages (very ?) slowly to our new system. 9 for the moment. We will continue slowly as each coverage has particularities.

[ialokim]

@prhod Yeah, that's cool, I've already noticed Portugal has been fixed. Great to hear you are already into the process of migrating!

Btw, were there any changes applied on Navitia's side to how the geojson for trips is provided? Or were there any more changes on the Nicaragua provider? I've noticed Transportr to not show the paths following the roads anymore although Navitia's still providing the information. I think this is a client-side issue but if you have a clue, please refer to grote/Transportr/issues/585.