added damage object

[matt-wirtz]

Added damage object to hold information regarding existing damages of vehicles. Included the damage object into the asset object.

[matt-wirtz]

Thanks Edwin for your review. I committed again.

As vehicle parts/components I have now: FRONT, REAR, LEFT, RIGHT, TOP, BOTTOM, INTERIOR, TIRE, ANCILLARY, OTHER

I didn't include:

• ENGINE: what kind of damages regarding the engine would you be able to see from outside? Additionally if the engine has issues the car sharer should not allow the car to be used anymore. So I think it's not necessary to include this part.
• SEAT: I think that is included in INTERIOR
• LEFT_FRONT, RIGHT_FRONT, REAR_LEFT, REAR_RIGHT: They overlap with LEFT, RIGHT, FRONT, REAR and therefore I think it adds uncertainty as where does LEFT_FRONT ends and where does LEFT start and so on. In my discussions it became clear that car sharers typically tend to have sophisticated methods of recording the precise location of damages. It's possible e.g. to mark the location of damages on a wire frame picture of the vehicle with a red dot. It's always possible to reduce precision and only expose the vehicle part/component. And here it's only differentiated between LEFT, RIGHT, FRONT, REAR. So I would suggest to leave the vehicle part/component enum to LEFT, RIGHT, FRONT, REAR. If it's necessary to further differentiate the left side into front, middle and rear I would rather suggest to add another level of location attribute e.g. sub-part/sub-component. Does this make sense?

The pictures of the damage don't need to be exposed when planning or booking. But they must be exposed when preparing the trip (POST /legs/{id}/event) before "SET_IN_USE" can be triggered. So I think they need to be part of the damage object. But maybe I overlook something here.

[edwinvandenbelt]

Thank you Matthias for your quick response! Regarding the enum: fine by me, if this suits the needs, who am I? Regarding the URLs: is it needed to show the pictures to the end user before the trip starts? Or is the information ('scratch on the rear') enough? If it is necessary to show these images (they might contain GDPR-conflicting stuff), then I'm fine with it. In that case, we should notify the implementing party (in the description) that GDPR issues can arise. If it is for reporting damages, I don't think we should handle this in the POST /legs/{id}/events (PREPARE or SET_IN_USE). If we do this in the support part, it can be called at any time (during the leg, at the finish). And, I think that is more intuitive to put it there. Or are you opting to skip the reporting part? Regards, Edwin

---

Van: matt-wirtz @.> Verzonden: dinsdag 5 december 2023 11:42 Aan: TOMP-WG/TOMP-API @.> CC: Edwin van den Belt @.>; Comment @.> Onderwerp: Re: [TOMP-WG/TOMP-API] added damage object (PR #517)

Thanks Edwin for your review. I committed again.

As vehicle parts/components I have now: FRONT, REAR, LEFT, RIGHT, TOP, BOTTOM, INTERIOR, TIRE, ANCILLARY, OTHER

I didn't include:

• ENGINE: what kind of damages regarding the engine would you be able to see from outside? Additionally if the engine has issues the car sharer should not allow the car to be used anymore. So I think it's not necessary to include this part.
• SEAT: I think that is included in INTERIOR
• LEFT_FRONT, RIGHT_FRONT, REAR_LEFT, REAR_RIGHT: They overlap with LEFT, RIGHT, FRONT, REAR and therefore I think it adds uncertainty as where does LEFT_FRONT ends and where does LEFT start and so on. In my discussions it became clear that car sharers typically tend to have sophisticated methods of recording the precise location of damages. It's possible e.g. to mark the location of damages on a wire frame picture of the vehicle with a red dot. It's always possible to reduce precision and only expose the vehicle part/component. And here it's only differentiated between LEFT, RIGHT, FRONT, REAR. So I would suggest to leave the vehicle part/component enum to LEFT, RIGHT, FRONT, REAR. If it's necessary to further differentiate the left side into front, middle and rear I would rather suggest to add another level of location attribute e.g. sub-part/sub-component. Does this make sense?

The pictures of the damage don't need to be exposed when planning or booking. But they must be exposed when preparing the trip (POST /legs/{id}/event) before "SET_IN_USE" can be triggered. So I think they need to be part of the damage object. But maybe I overlook something here.

— Reply to this email directly, view it on GitHubhttps://github.com/TOMP-WG/TOMP-API/pull/517#issuecomment-1840489569, or unsubscribehttps://github.com/notifications/unsubscribe-auth/ACPLCNUYR66TIME7I46CG3TYH33A5AVCNFSM6AAAAABADABX7GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNBQGQ4DSNJWHE. You are receiving this because you commented.

[matt-wirtz]

Regarding the pictures showing the damages: Before starting to drive the vehicle one has to confirm that all visible/obvious damages are already part of the existing vehicle damages list. Otherwise the hotline of the TO must be informed about any additional damages. For the process of checking all damages I think it's very important to have the pictures as an additional aid available. So the pictures need to be available in the trip execution phase, not planning or booking phase. To get into the trip execution phase, the booking phase needs to be completed. In the booking phase the contract between user and TO is established, terms&conditions agreed on. Are there any GDPR topics regarding the pictures of damages left? The pictures of course should not disclose who made the picture or show any persons on it. But I think that is the responsibility of the TO.

Should I include the info that the damage object should only be exposed when in the trip execution phase?

I do opt for skipping the reporting part. For the car sharers this approach doesn't fulfill their requirements regarding precise location of the damage and therefore might raise the probability of reporting the same damage repeatedly.

[edwinvandenbelt]

It makes sense, let's keep the URLs in the damage object. We have to think about how to report the damage in the next version. Could you also write a page on the wiki on how to use the damage object? I've added you to the list of maintainers of this github site.