Consider just using unique IDs instead of UUIDs

[aickin]

From an implementer's perspective, I'd argue that requiring that vehicles, devices, and trips all have UUIDs could be a bit of pain, and I'm not totally sure why it's required. Since a provider is presumably in charge of all their fleet data, they would have the ability to allocate unique IDs without using UUID. What do you think about just changing this to String type and requiring that it be unique by provider?

[asadowns]

I don't believe the spec specifies that vehicle_ids must be UUIDs since these must be displayed on the vehicle. For the others I think UUID seems like the right approach. Two cents.

[aickin]

@asadowns Thanks for the response! As I read it, there is a UUID to identify vehicles in the agency API, but it's called unique_id. For example, it's a parameter in register_vehicle.

[asadowns]

Ahh. good point. I guess it's clarified a bit on the provider side where they specify what the device_id is. I interpreted that this unique_id and the device_idbeing synonymous but it probably should be spelled out more clearly you're right.

MDS defines the device as the unit that transmits GPS signals for a particular vehicle. A given device must have a UUID (device_id below) that is unique within the Provider's fleet.

Additionally, device_id must remain constant for the device's lifetime of service, regardless of the vehicle components that house the device.

[thekaveman]

@asadowns your interpretation of the provider side matches mine. Probably some of the wording/field updates didn't make it over to the agency side, but I think the idea is to be as consistent as possible on both.

vehicle_id is whatever the provider uses on the vehicle itself to identify that vehicle from others. It should be visible to a human looking at the vehicle on the street (identifier meant for humans).

device_id is a UUID assigned to the GPS unit attached to the vehicle. According to #37 this is supposed to remain constant for the lifetime of the GPS unit (regardless of maintenance/re-attachment to other vehicles, etc.) to track it over time in the data (identifier meant for machines).

More context into the decision to use both can be had in #32; vin was subsequently renamed to the current vehicle_id for consistency of field name format. Some recent discussion on #51 calls some of these assumptions about device_id into question.

As for whether UUID or string is best for these identifiers meant for machines, I think that is still up for debate.

[hunterowens]

We very quickly noticed performance problems in our data warehouse when we introduced having to index on solely a string (vehicle_id + provider_id).

Having a UUID allows us to efficiently aggregate data from across many providers, this stack overflow post was helpful for me in understanding why we should get UUID. Which is that we are generating a distributed index across providers.