Add performance index

[felixkluge]

Added performance index calculation as discussed in https://github.com/mobilise-d/mobgap/issues/122

[felixkluge]

Please note that formatting did some additional changes in gsd/evaluation.py

[felixkluge]

Tests still to be added - any suggestions?

[AKuederle]

@a-mosquito Can you have a look at this? In particular considering the changes that you made for error calculation. Do you see a way this could be integrated better with the other error calculation stuff?

[a-mosquito]

It should be possible to integrate that to the syntax introduced by #126. We could model the performance index calculation as a chain of transformations & aggregations:

• The normalizations can be implemented as transformations and calculated using apply_transformations.
• The aggregations can then be applied using apply_aggregations.
• For the last step of weighting and summing up the results, we would either have to add an additional function, or leave it to be done on user side.

Some considerations for the practical side of implementing this:

• It might require one or two lines of preprocessing the input data on user side to bring the data in the correct format, which we could however show in the example
• We would have to figure out whether we provide the normalization functions, the transformation and aggregation configurations, and the weights for both approaches as defaults or only show in an example how they can be assembled.
• For the normalizations, we could either provide one function with criterion and normalization as args, which would require wrapping them in a (named) lambda for modifying the args; or split them into several functions for each possible configuration. I think the latter would be easier, because currently, only the configurations criterion="benefit" ; normalization= None and criterion="cost" ; normalization="exponential" are used, which would require only two default normalization functions.
• For the aggregations, no more work is required because all required aggregations are already implemented. Unless we decide to include the multiplication with the weights in the aggregations, but I think that's too unintuitive/inflexible.
• When not including the weights in the aggregations, we would have to find an elegant way to provide them as defaults.