Technical Assistance Subgroup Meeting #2 (October 7, 2021) - usdot-jpo-ode/wzdx GitHub Wiki

Technical Assistance Co-chairs Chuck Felice and Shane Zumpf presented the linked slide deck which focused on the new Institutional Buy-In documents, proposed reorganization of business rules on GitHub, and the future of the subgroup.

Poll Questions

Do you think that the Technical Assistance Subgroup should be rechartered for the next development cycle?

  • Yes, with the same focus (20%)
  • Yes, with a different focus (60%)
  • No (20%)

If the Subgroup is rechartered, what would you like to see the group work on?

  • Creating videos to explain how to create a feed, to show how to access resources, or to facilitate institutional buy-in. (20%)
  • Produce a document explaining the difference between new and existing versions of the specification. (20%)
  • Produce a user guide to help with feed creation (50%)
  • Other (please put suggestions in the chat) (10%)

Discussion/Questions

Ross Sheckler: What resources has this group produced thus far? How many times have these resources been accessed?

Shane Zumpf: We have the Early Adopters Guide based on interviews we conducted with WZDx users and what we’ve learned from those interviews. Chuck Felice went through our document on institutional buy-in (coming soon to GitHub). We've also pushed out a document helping to clarify the business rules of the specification. Molly Behan is going to look into seeing if the docs we've been producing have been accessed.

Jacob Brady: The Technical Assistance subgroup should consider creating software libraries for WZDx. Maybe .NET since most of the people I talk to are using it. These libraries would implement the models as classes and generate feeds from those classes so that agencies can rely on the libraries to limit the amount of work they need to do and make sure they're doing it right. However, I’m not sure if this team can do that or organize the effort.

Shane Zumpf: I like that suggestion, we could define the interface for the C# library, but that would be useful for states to use to generate a feed.

Eric Kolb: Could we also provide conversion/formatting tooling?

Chuck Felice: Could you expand on this?

Eric Kolb: I’m riffing on what Jacob said, provide tooling for a structured feed format from shapefiles or other formats and vice versa so any less sophisticated user can parse the feed into a shapefile for their own use.

Maaza Mekuria: A format like GeoJSON or WKT would be more useful. GeoJSON files are more portable and shapefiles are quite limited.

Nisar Ahmed: This subgroup should encourage data consumers to adopt WZDx. We are focusing on producers which is great, but if consumers aren’t using the data producers won't be encouraged to go through the process of creating these feeds. We work with stakeholders on both sides in the San Francisco Bay Area.

Chuck Felice: Could you see us having a consumer buy-in doc in addition to our producer buy-in doc? Nisar Ahmed: I haven't read the current buy-in doc so I don't have a perspective on it, but seeing Eric Kolb nod his head makes it sound like a good idea to me.

Shane Zumpf: Eric, if we were to produce a doc like that, what would be most helpful?

Eric Kolb: My team is comfortable with the specification, so it wouldn't necessarily be beneficial to my organization. But I was thinking that if we could get other consumers involved in this, this would create a flywheel effect where consumers encourage producers to create data, which would attract more consumers, and so on.

Shane Zumpf: What do you think would convince other organizations to be on board?

Eric Kolb: Typical feed ingestion platforms may be useful. People use ESRI’s GeoEvent server, for example, so maybe you could figure out how to plug into the GeoEvent server using a WZDx feed. I'll think of some other stuff but this is all I have off the top of my head.

Nisar Ahmed: It may also depend on the consumer's application. In my experience working with GTFS and GTFS realtime, some consumers like working with bulk data but others like it in small amounts via APIs. In the Bay Area we produce GTFS and GTFS realtime feeds but we also have APIs created following the Siri and NetX standards. Some consumers like that, they go straight to APIs because they want a small amount of data, they don't want to have to maintain a big server. I don’t know if the spec allows for that kind of data delivery, but that could be one thing to look at.

Chuck Felice: We were wondering what the future of the WZDx feed is as far as governance. Do we go to an open-source community have those folks develop our APIs?

Nate Deshmukh-Towery: One of the future homes we're exploring, the Open Mobility Foundation, is something like that, different from the more traditional SDOs.

Nisar Ahmed: One use case is a car company with autonomous vehicles. I don’t know if they would like to have all the world's data in one place and communicate info to the car or if they would just like small amounts of data from the local source.

Chuck Felice: These are really good questions. Curtis Hay works for GM and he gives us good info on how a large auto company would use this data. This is kind of along the lines of what you've brought up. We're hoping some other manufacturers will jump on board. UDOT is talking with one of them soon and I'm going to ask about it.

Nate Deshmukh-Towery: Would a reference / sample set of data be useful for data consumers to “try out” using WZDx?

Eric Kolb: It would be good to provide "test data" that reflects upcoming version releases so that it could be tested by consumers.

Jacob Brady: The examples section of the repository generally provides that.