Lost & Found

[openmobilityfoundation]

Lost & Found

[hunterowens]

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]

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

[thekaveman]

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]

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]

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]

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.

[HenriJ]

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]

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]

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