Adding Enforcement Attributes to Demand Data

[jacobmalleau]

Adding the ability to handle enforcement related events in the CDS Curb Events and Metrics data. Based on work with LADOT in the SMART Grant Collab.
Resolves #173
Resolves #174

[schnuerle]

We will be talking about this at today's public Curb Working Group meeting.

[schnuerle]

From our Curb Working Group meeting today:

• Could add an 'enforcement' array key value object that can be part of Events to be captured: muni code, violation name, enforcement action taken, fee/cost, ticket id
• Also applies to curb objects, how to connect to these objects?
• Minneapolis and San Joes support this

SFMTA pushes our parking citation data to a public open data feed, and it would be great to have this information available in CDS events.
Current feed: https://data.sfgov.org/Transportation/SFMTA-Parking-Citations-Fines/ab4h-6ztd/about_data

LADOT does as well: https://data.lacity.org/Transportation/Parking-Citations/4f5p-udkv/about_data

[jacobmalleau]

Added a commit to connect Events to Objects, but held off on adding the key-value pairs as I want to see if anyone else has thoughts on attributes to add:

• muni code
• violation name
• enforcement action taken
• fee/cost
• ticket id
• Others?

[schnuerle]

... held off on adding the key-value pairs as I want to see if anyone else has thoughts on attributes to add:

Where would these key value pairs be added?

[schnuerle]

@jacobmalleau I think go ahead and add a new Enforcement data type with these fields, like we created for External References. Then we can talk about what enforcement fields to add/remove/edit beyond your short list.

You can then add the new enforcement data object as a field in Events, like with External References in Events (bottom of table) and Curbs.

[schnuerle]

Thanks, looks good, I made some formatting updates, and changed it to just 'Enforcement'. The 'External Reference' name was really just because it was a reference to an external thing.

[schnuerle]

We will be reviewing this at tomorrow's public Curb Working Group meeting. However we won't have much time to discuss, so leave your comments and suggestions here as general or inline comments to spark changes before the CDS 1.1 release is made.

[JohnLundstrom-Minneapolis]

Added a commit to connect Events to Objects, but held off on adding the key-value pairs as I want to see if anyone else has thoughts on attributes to add:

• muni code
• violation name
• enforcement action taken
• fee/cost
• ticket id
• Others?

I'd recommend the following fields, dependent upon how common they are in other citation systems:

*Status (for us this has been a two character field for the primary entry, such as "IS" for issued, "VA" for void approved, and "WR" for warning).

*Plate AND State if transmitting such information

Finally, how are we handling the location in this concept?

[bhamlinSDOT]

Added a commit to connect Events to Objects, but held off on adding the key-value pairs as I want to see if anyone else has thoughts on attributes to add:

• muni code
• violation name
• enforcement action taken
• fee/cost
• ticket id
• Others?

I'd recommend the following fields, dependent upon how common they are in other citation systems:

*Status (for us this has been a two character field for the primary entry, such as "IS" for issued, "VA" for void approved, and "WR" for warning).

*Plate AND State if transmitting such information

Finally, how are we handling the location in this concept?

Agree w/ @JohnLundstrom-Minneapolis that Status would be helpful.

For location - our citation data is currently lat/long coords.

We also have date/time that the citation was written. I assume the date/time + location (if not associated with a curb_zone_id) would be captured in event_location and event_time?

[schnuerle]

@JohnLundstrom-Minneapolis : @bhamlinSDOT is right. Date, time, and location and other fields are captured in the general Event data.

I assume the date/time + location (if not associated with a curb_zone_id) would be captured in event_location and event_time?

[michael-danko-passport]

There are a few places where we are using citation, ticket, and violation and I think we should be consistent throughout the spec. I would propose the following:

• citation -> Replaces the usage of ticket and represents a single instance of a broken infraction.
• violation -> The city or municipal code that was violated

If we can get consensus in one direction or another there are some additional changes that will need to be made.

[schnuerle]

There are a few places where we are using citation, ticket, and violation and I think we should be consistent throughout the spec. I would propose the following:

• citation -> Replaces the usage of ticket and represents a single instance of a broken infraction.
• violation -> The city or municipal code that was violated

If we can get consensus in one direction or another there are some additional changes that will need to be made.

Are you thinking here, for ticket_id and ticket_cost?

https://github.com/openmobilityfoundation/curb-data-specification/blob/jacobmalleau-enforcementimprovements/data-types.md#enforcement

Is a ticket different than a citation? Can there be a ticket ID and a citation ID too, or are those really always the same thing?

[schnuerle]

@JohnLundstrom-Minneapolis and @bhamlinSDOT can you propose a definition of a status field?

It should be an open ended 'string' type, so you can use two letter abbreviations if needed, or other cities can use what they need.

[kenyaw]

There are a few places where we are using citation, ticket, and violation and I think we should be consistent throughout the spec. I would propose the following:

• citation -> Replaces the usage of ticket and represents a single instance of a broken infraction.
• violation -> The city or municipal code that was violated

If we can get consensus in one direction or another there are some additional changes that will need to be made.

Are you thinking here, for ticket_id and ticket_cost?

https://github.com/openmobilityfoundation/curb-data-specification/blob/jacobmalleau-enforcementimprovements/data-types.md#enforcement

Is a ticket different than a citation? Can there be a ticket ID and a citation ID too, or are those really always the same thing?

@schnuerle In San Francisco, we utilize citation for parking violations, so the change from ticket seems fine.

Regarding the definition for violation, cities enforce infractions from various levels of government. A more descriptive definition statement could be "The city/municipal, county, state, or provincial code that was violated."

[schnuerle]

Based on @kenyaw's comments, I think you can align things to citation, and away from ticket @michael-danko-passport. And update the violation description to "The city/municipal, county, state, provincial, or federal code that was violated." Note I added federal to that list.

[JohnLundstrom-Minneapolis]

@JohnLundstrom-Minneapolis and @bhamlinSDOT can you propose a definition of a status field?

It should be an open ended 'string' type, so you can use two letter abbreviations if needed, or other cities can use what they need.

I'm realizing that we wouldn't be capturing changes to the status over time (such as when a citation is cancelled on some future date), as those wouldn't be distinct curb events, but we still have some options at the time the citation is issued, mainly delineating between a warning and an active citation. My first attempt is:

"Describes the disposition of the citation at the time it was issued which can be used to identify alternate use cases such as warnings."