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

Lost & Found #67

Closed
bhandzo opened this issue Sep 13, 2018 · 9 comments
Closed

Lost & Found #67

bhandzo opened this issue Sep 13, 2018 · 9 comments
Labels
Agency Specific to the Agency API enhancement New feature or request Provider Specific to the Provider API
Milestone

Comments

@bhandzo
Copy link
Contributor

bhandzo commented Sep 13, 2018

The current status changes don't account for vehicles which go missing (for any number of reasons). These vehicles are not available to be ridden, and most likely are also not in the public right of way. There are two ways this could go:

  1. Add a new event_type of lost and exclude those vehicles from cap counts.
  2. Add a new event_type_reason of lost to the removed event_type

Either way, there should then be an event_type_reason for available of found

@hunterowens hunterowens added this to the 0.1.1 milestone Sep 14, 2018
@hunterowens
Copy link
Collaborator

Aside from adding lost, we should add stolen.

@bhandzo can you prepare a PR for adding those event types and event type reasons. @LADOTBikeshare and I will work on how it applies to the cap.

@mattwigway
Copy link

Damaged might be a good one as well (flat tires, etc.)

@thekaveman
Copy link
Collaborator

So is the idea here that the provider would mark, within their system, a device as lost etc - and this would generate an MDS Provider status_change with the associated data?

I have some follow-up thoughts and questions:

  • how does a provider know that a vehicle is lost? Do they know enough about the vehicle to know the event_time and event_location where it was lost (as required by a status_change event)?

  • what is the definition of lost, and does every provider now and into the future agree on this definition? If the provider's system loses track of the device (and marks it as lost with a status_change as outlined above), but I as a customer find it on the street (or in a bush, or in the creek, or whatever...), can I begin a trip with that device? Or has the provider's system locked it because it was marked as lost, and now no one can use it until it is "found" and unlocked? Does every provider handle this situation the same?

  • Assuming we wanted to add some kind of event for lost devices and we answered the above questions, I disagree about event_type:lost. I think this should use the existing event_type:unavailable or event_type:removed (depending on the answer to the scenario I posed above) with an event_type_reason:lost

  • I'm not sure that all of this matters for a regulatory agency. If a provider considers their device to be "lost" - by definition that means the provider doesn't know where it is. They don't know if it's blocking the sidewalk, an ADA ramp, in the ocean, etc. From a total devices allocated point of view, the device is still out there, because it hasn't been explicitly brought back in.

@thekaveman thekaveman modified the milestones: 0.1.1, Future Sep 26, 2018
@thekaveman
Copy link
Collaborator

Closing this as the conversation seems to have died off. Feel free to re-open with any additional comments / follow-ups on the thoughts above.

@billdirks
Copy link
Contributor

This is becoming more of a pain point. Vehicles are getting lost/stolen and, with no status event to indicate this, they appear to remain on the street indefinitely. While consumers can come up with methods to guess at when a vehicle has disappeared from the PROW, it seems like the feed should be the closest to the truth as the operator knows. It feels like operators may currently be dealing with lost/stolen vehicles in different ways since it is not defined by the spec. As @thekaveman points out, the spec will need to be clear on what lost or stolen means.

As a side note, I am not too concerned about the scenario where a vehicle is marked lost but is actually still available to rent because it would be immediately discoverable from the status feed.

@marie-x
Copy link
Collaborator

marie-x commented Sep 18, 2019

Agency uses inactive to reflect vehicles that are missing/lost/stolen/etc. It would be simple to add "inactive / missing" to the table to reflect that a vehicle is short-term missing, and "inactive / deregister" to indicate semi-permanently gone (definitely destroyed or recycled, missing for more than a month and unlikely to be recovered, etc.) Any subsequent event that isn't inactive would bring it back to PROW or removed.

I don't know if we want to cram this in to 0.4.0, but it's an easy non-breaking change, and I'd be happy to write the PR.

@sarob sarob added Agency Specific to the Agency API enhancement New feature or request Provider Specific to the Provider API labels Dec 19, 2019
@HenriJ
Copy link

HenriJ commented Jan 3, 2020

As "missing" is already an event_type_reason in the Agency API, I guess we can remove the "Agency" tag from the issue.
@Karcass what do you think ?

@marie-x
Copy link
Collaborator

marie-x commented Jan 8, 2020

Agreed.

I think there is still an open question of whether inactive should be forked into inactive (retired, destroyed, missing for a long time) and missing (not sure where it is but expecting to get it back "soon"). This would apply to both Agency and Provider.

@schnuerle
Copy link
Member

I think we have this resolved with 1.0.0 now! It will have 'missing' and 'located' values for event types between some states.

@schnuerle schnuerle modified the milestones: Future, 1.0.0 Sep 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Agency Specific to the Agency API enhancement New feature or request Provider Specific to the Provider API
Projects
None yet
Development

No branches or pull requests

9 participants