You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I've forked the repository as I needed to add support for additional optional fields that are not in the GTFS standard.
I've done this because a number of cities provide additional information regarding their public transit, such as "brigade_id" (a brigade refers to the next bus in the current line/route), among other useful information.
Would you be willing to merge such a feature to this crate? It would be something along these lines:
sorry for the delay, I don't know how I missed this issue 😕
hum I'm not completely convinced as adding this will add an overhead for all (and on trips, where there can be quite a big number of them) and miss a bit the point of having real types for the GTFS.
However I understand why you need this, and I'm not sure the performance issues will really bother some people, but I'd vote to hide this behind a feature flag.
However, I decided against the idea I mentioned in the issue, due to a quirky behavior in serde-csv (BurntSushi/rust-csv#151) where deserializing a String "010" ends up being interpreted as an integer (10).
I've opted into a different solution (readme or docs if I can upload it to crates.io), as well as handled most of datasets defined in the GTFS reference.
On top of that, I only read the necessary files instead of everything at once :)
Edit: A colleague of mine is asking whether or not this should be eventually a pullrequest to this repository as a new version. What do you think?
Hi, I've forked the repository as I needed to add support for additional optional fields that are not in the GTFS standard.
I've done this because a number of cities provide additional information regarding their public transit, such as "brigade_id" (a brigade refers to the next bus in the current line/route), among other useful information.
Would you be willing to merge such a feature to this crate? It would be something along these lines:
Where
Value
is a catch all wrapper for deserializationThe text was updated successfully, but these errors were encountered: