Builder debrief on signal scheduling in VZA App

[amenity]

Objective

• Discuss approach and next steps fo extending the VZA App to include scheduling for APD signal-minding assignments.
• Do we need to alter the VZA Location model to accommodate locations, or can we just have a new Location Type, Signal?
• How should we get signal locations into the VZA app?
  • Regular manual import from AMD Data Tracker? We'll be doing annual updates of school locations from an AISD CSV, but this might not be frequent enough for signals.
  • Email triggers when new signal is added in AMD Data Tracker ---> DTS GIS manually adds signal to VZA App
  • Same as Lewis' workflow for other locations: Billy add signal, automatically set to status of Needs GIS and kicks off email to Jaime & Alan, they manually add it to VZA AGOL feature set and add the AGOL_Feature ID and set Status to Active from Knack Builder
  • Script - @SurbhiBakshi suggested Python + Airflow like we're doing with Dockless Mobility
• What do we want to shoot for as far as Schedulers' permissions - e.g. visibility into others' schedules

Participants

Surbhi, Amenity, John, Diana

Agenda

See notes from previous meeting here. Here is Billy's example of how he currently schedules.

---

• [x] Schedule meeting 5/26 2pm
• [ ] Meet and take notes
• [ ] Create resulting issues

[johnclary]

How should we get signal locations into the VZA app?

I would say email trigger at first, then we can implement an integration. Fairly straightforward to integrate (8hrs dev time).

The main issue I foresee is the it does not seem that new signal records are being created until late in the process (e.g., turn-on). So AMD needs to get better about having these created early in the process if APD officers are scheduled for signal construction.

[johnclary]

What do we want to shoot for as far as Schedulers' permissions - e.g. visibility into others' schedules?

I don't think we should design the app around this unless there is some major risk of schedulers seeing other schedules. How many people do we envision having access to view schedules?

[johnclary]

Do we need to alter the VZA Location model to accommodate locations, or can we just have a new Location Type, Signal?

Probably another location type, since these are discrete points rather than stretches of road?

[amenity]

Thanks, @johnclary! Just to clarify that last one: You think that adding a new Location_Type for signals would be enough? I'd prefer not to add a new object or field. And yes, these are points rather than polylines, but that difference is captured in the GIS data itself. In my mind, these can be stored in Knack the same way, assuming AGOL_Feature_ID can link them.

[johnclary]

Cool—I actually meant additional object, but i hear ya. In my data brain it seems like poor form to keep these in one object but for the app experience and maintenance in Knack, it makes sense to just add a location type for Signals to the existing object sounds find.

Let's talk about how we link the actual GIS data for these. They already exist in a GIS layer that is populated from the AMD Data Tracker.

[amenity]

@johnclary Actually 😄 ...after discussing with @SurbhiBakshi and @dianamartin, leaning towards a separate "Signals" object, probably with the same fields as the "Locations" object. A couple reasons:

• This will allow us to keep the 900+ signals out of the drop-down Lewis uses when he creates VZA assignments. (Remember that we're relying on predictive typing. e.g. Schoo- to allow him to quickly narrow down the drop down by type or APD sector.)
• I suspect referencing two different feature classes (schools+streets/polylines and signals/points) from one object might be tricky - you'd have to use the Location_Type field to pass an additional parameter to get to the right feature class

Roles:

• Need to discuss with Jen and Lewis, but Amenity's preference is for there to be a single "Scheduler" role and for schedulers to have full visibility into each other's schedules.

Other discussion points:

• Right now we have an "Intersection" location type for Lewis and this is drawn as a "+" polyline. Is there any benefit to allowing/encouraging Lewis to directly reference the signals object instead?
• @SurbhiBakshi suggested that we could overwrite the Signals records periodically rather than update them manually.

Questions:

• How do we want to map AMD Data Tracker fields to VZA fields? Should the Signals object have different fields/columns than the the Locations object?

[amenity]

@dianamartin @SurbhiBakshi - finally got my notez up, please add anything I missed.