Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for optional extra fields #77

Open
irexiz opened this issue May 24, 2021 · 2 comments
Open

Support for optional extra fields #77

irexiz opened this issue May 24, 2021 · 2 comments

Comments

@irexiz
Copy link

irexiz commented May 24, 2021

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:

#[derive(Debug, Serialize, Deserialize, Default)]
pub struct RawTrip {
    #[serde(rename = "trip_id")]
    pub id: String,
   // snip!
    #[serde(flatten)]
    pub extra: HashMap<String, Value>,
}

Where Value is a catch all wrapper for deserialization

#[derive(Serialize, Deserialize, Debug, PartialEq, Clone)]
#[serde(rename_all = "snake_case")]
#[serde(untagged)]
pub enum Value {
    Bool(bool),
    U64(u64),
    I64(i64),
    Float(f64),
    String(String),
}
@antoine-de
Copy link
Collaborator

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.

@irexiz
Copy link
Author

irexiz commented Jun 28, 2021

Hi @antoine-de

I've kind of got impatient and ended up writing another library based off of this one (I hope you don't mind) as I needed that feature internally.

https://github.com/irexiz/gtfs-parser/tree/master

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?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants