Web Conference 2022.07.26 Curb - openmobilityfoundation/curb-data-specification GitHub Wiki

Web Conference - Curb Working Group

  • Every other week Tuesday call at 9am PT, 12pm ET, 5/6pm CET

Conference Call Info

Meeting ID: 898 5980 7668 - Passcode 320307
https://us02web.zoom.us/meeting/register/tZ0lcuCgrjwsHNyZRagmc86b12iCmWGBHfjq

One tap mobile: +13126266799,,89859807668#,,,,*320307# US (New York)

Dial by phone: +1 929 436 2866 (US) (Find your local number)

Agenda

Main Topics

  1. Welcome (5 mins) - Jacob Larson, Omaha
  2. Spec Brainstorming Session - next releases (50 mins)

Organizers

  • Hosts: Jacob Larson, Omaha
  • Note Taker: Marisa Mangan, SANDAG
  • Facilitator: Michael Schnuerle, OMF
  • Outreach: Angela Giacchetti, OMF

Recap

Notes

  • Jacob provided a brief overview of CDS development and participants

  • Angela introduced new member, Vade, who is doing work in the curb space

  • Michael Danko, Passport - API versioning discussion he initiated in response to OpenAPI discussion

    • Versioning follows a major v minor syntax. New fields added doesn’t break functionality
    • OpenAPI has versioning and it's a question that comes up as we determine how we document our APIs in CDS
    • Angela G.OMF - in MDS world we have not versioned the APIs but unsure if there's a specific reason
    • Good question for Michael next time and we'll flag as a follow-up
    • Brian Hamlin, Seattle DOT: would it be challenging to track separate versioning between CDS and each API within CDS? Michael: yes, challenging if we went with both version methods. All 3 APIs are in 1.0.0. We may increment versions to curb API for example and it may become difficult to understand

  • Independent versioning can help you by making corrections as a patch for all 3 APIs.

  • CDS as a curb data spec - CDS contains these APIs and they have various versions within

  • Kenya Wheeler, SFMTA - how does this proposal align with MDS version guidance? Angela - we use one version number to apply to MDS and all of its APIs. https://www.openmobilityfoundation.org/about-mds/mds-version-guidance/

  • While a city can choose to only use one API, we package it together.

  • Angela G. - is this laid out in our architectural landscape in that we have to do it a certain way? Is there a specific reason for doing it that way? Also, questions Michael S. is best suited to answer.

  • Brian H. - sees some benefit to having versions for each API to build in flexibility. Curb API could stay at one version while events is evolving more quickly

  • Angela G. - standard versioning is stronger the less version spread you have. Each API has different endpoints within. Endpoints as different features

  • Michael D. - by building multiple APIs to share the same version, it may make it more straightforward but if a city wants to adopt a new version it will make it difficult. Events would still be incrementing versions depiste keeping one version for entire spec.

  • Angela G. - Could make version spread worse by forced bundling (one version that applied to all APIs)

  • Kenya W. - consider a different approach: way to create a beta structure so as changes being considered and cities willing to use them can advance them. Beta as a testing ground model? Can that work?

  • Angela G. - we do have a beta mechanism. When we put in a new feature it's an endpoint we release as beta. Never done beta for a whole API though yet.

  • Michael D. - if you make a change to one API, does that mean there's multiple release candidate.

  • Matt Davis, Populus: It would affect the release process in general, e.g. how you name and create the git tags that define a release.

  • Angela G: end by having Michael S weigh in next

  • Flowbird initiated discussion to rename attribute "rate" in Rule object into "rates" #103 lecuretFlowbird

From https://github.com/openmobilityfoundation/curb-data-specification/issues/103

  • Michael D. - This would be a breaking change

  • Angela G. - is the context being referred to here in line with its common usage?

  • Michael D. - first one is an array of the other values. What are the rates for a given location for a given day (i.e., list of rates).

    • "Rate in cents" could be an additonal edit to help clarify we're talking about a cent value
    • Michael will summarize comments and add it to open issue 103

  • Push v pull issue #99 (Michael D) https://github.com/openmobilityfoundation/curb-data-specification/issues/99

    • Events API - originator of events to enable searching events. Meant to be occurring in real time but not necessarily efficient.
    • Proposing using the same format of what makes up an event but push out in real time without making providers query them
    • Not suggesting a replacement of the events API, but CDS does not define how to push events, it only describes the pulling mechanism
    • Angela - any learnings from MDS?
    • Matt Davis, Populus: didn’t see anything in events API within CDS asking for a timeline of events
    • Michael D - instead of searching hourly, you'd just increment what the time window would be to receive the applicable number of events created within those windows
    • Matt - yes, it’s by hour in MDS so 24 requests per day. Don't see anything in CDS that allows you to get a specific time range of data
    • Populus doesn't have a particular need for the push mechanism at the moment. MDS push schema not the same as pull.
    • Previous CDS curb architectural decisions including push v pull https://github.com/openmobilityfoundation/curb-data-specification/wiki/Curb-Architectural-Decisions#push-vs-pull
    • Michael D - arch doc says pull as easier but is there value in doing both?
    • Brian - if you just went hard on push, if internet goes down, you might lose vital data. Push makes sense to get real time data as not every city will be able to set it up. Can see scenarios for how push may align with how cities want to manage curbside data
    • Michael D - reconciliation can still occur on a less frequent basis. Or one can be a fall back if the other fails
    • John Good - re: fleet providers pushing data, is there consideration on frequency?
    • Angela - worthwhile to reopen convo for next version
    • Brian - helpful to hear more use cases to help inform reasons for using both. Angela - yes and how pressing are they?
    • Angela - more focused session on these issues to get right people in the room
    • Michael D - will open an additional issue re: date filters to help query on event endpoint
    • Jacob - can you also add an example that we can add to the events example section? Example for the time query
    • Angela - final item for feedback. There's another parking standard APDS - OMF has been finalizing a comparison and feedback doc. Sharing a link to WG for more feedback
    • https://docs.google.com/document/d/17Em4eD6QRieaBnLV552LGpLSh7Tmq4moc41zJ-6iwqw/edit?usp=sharing If you use both specs or are planning to use both specs please check it out

Action Items

  1. Continue to discuss API versioning and seek Michael S's feedback given MDS experience
  2. Continue to discuss beta mechanism for versioning, again seeking Michael S's feedback
  3. New issue to be opened on date filters to help query on event endpoint
  4. Curb WG is asked to weigh in on APDS comparison doc: https://docs.google.com/document/d/17Em4eD6QRieaBnLV552LGpLSh7Tmq4moc41zJ-6iwqw/edit?usp=sharing