ERSAD: Add information display and information desk inputs

[solita-sabinaf]

Summary

In facilities tab: new information display input.
In assistance tab: new information desk input.

Both are defined on a stop place level only.

Issue

• We need these to support these ERSAD fields;
• The implementation just extends the current site facility set with two new fields: passengerInformationEquipmentList and passengerInformationFacilityList. Nothing special;
• Two new components were added, InformationDesk and PassengerInformationDisplay, to handle these new inputs;

The XML behind:

<facilities>
	<SiteFacilitySet id="FSR:SiteFacilitySet:510" version="1">
            <MobilityFacilityList>boardingAssistance</MobilityFacilityList>
            <PassengerInformationEquipmentList>informationDesk</PassengerInformationEquipmentList>
            <PassengerInformationFacilityList>passengerInformationDisplay</PassengerInformationFacilityList>
	</SiteFacilitySet>
</facilities>

Unit tests

• Unit tests added/updated
• Manual verification done

[a-limyr]

This is a well-structured implementation that follows established patterns. The code is clean, properly integrated across all layers and moves the application towards TypeScript. I found a type issue and some other minor things that might not be an issue.

Good job!

[a-limyr]

Is this supposed to be a list also? If not then perhaps the name should be passengerInformationEquipment?

[solita-sabinaf]

Good catch! This was originally due to backend's netex model (part that is bound to external library) having it as a single value (despite name suggesting it's a list), but since in the end I made it so that tiamat's own netex model has it as a real list, I think I forgot to tune up this spot along

[a-limyr]

Would it be an idea to have a else if here to verify that the type is stopPlace? And not just assume? At least it would be more readable.

[solita-sabinaf]

Not sure, the "entity" usually implied that it's either a quay or stopPlace (e.g. type EntityType in model), so if a method was about updating an entity, maybe there aren't other use cases coming around 🤔 But then I do remember that in the UI components there been some places where the value of "type" that can be a "parking"...

[solita-sabinaf]

But maybe for the sake of readability "else if" would make it more clear, I'll add it

[a-limyr]

This is the only enum in use from this set of enums. Is this intentional or have you forgotten to add support for the other enums in the UI? If it is there for future implementations it is fine.

[solita-sabinaf]

These just tagged along from the backend, could be used in future (currently only info desk is) but not yet (and probably won't be done by us)

[a-limyr]

This is the only enum in use from this set of enums. Is this intentional or have you forgotten to add support for the other enums in the UI? If it is there for future implementations it is fine.

[solita-sabinaf]

These just tagged along from the backend, could be used in future (currently only passengerInformationDisplay is) but not yet (and probably won't be done by us)

[solita-sabinaf]

@a-limyr, thank you for the review, great points! The changes been made, I'll ping once the backend is merged

[solita-sabinaf]

@a-limyr, the backend is now merged 🚀