Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add: Option for a new transfer feeder payment algorithm #7935

Open
wants to merge 1 commit into
base: master
from

Conversation

@JGRennison
Copy link
Contributor

JGRennison commented Jan 14, 2020

The original algorithm pays intermediate legs in feeder systems based
on the start and end stations of that particular leg.
This tends to result in large negative payments on the final leg for
journeys with many feeder legs, as the overall feeder payment increases
with the number of legs, and the final leg is penalised for discrepancies
between the previous leg payments and the actual payment for delivery
from the source to the destination.
The feeder share setting is a partial mitigation, however it is difficult
to tune as a suitable value depends on the number of legs and the network
topology, which are often not the same for all vehicles.

The new incremental algorithm pays the cargo payment from the source
station to the end station of the current leg, minus any previous
transfer feeder payments for each leg.
This prevents unbounded increase of feeder payments and therefore avoids
the issue of excessive negative payments on the final leg.
Feeder payments may be negative, e.g. in the case of poorly performing
or highly indirect legs. This is better than penalising the final leg.
This mode reduces the need to tune the feeder shares setting to the
current network.

The feeder share setting applies in the existing way for both modes.

The original algorithm pays intermediate legs in feeder systems based
on the start and end stations of that particular leg.
This tends to result in large negative payments on the final leg for
journeys with many feeder legs, as the overall feeder payment increases
with the number of legs, and the final leg is penalised for discrepancies
between the previous leg payments and the actual payment for delivery
from the source to the destination.
The feeder share setting is a partial mitigation, however it is difficult
to tune as a suitable value depends on the number of legs and the network
topology, which are often not the same for all vehicles.

The new incremental algorithm pays the cargo payment from the source
station to the end station of the current leg, minus any previous
transfer feeder payments for each leg.
This prevents unbounded increase of feeder payments and therefore avoids
the issue of excessive negative payments on the final leg.
Feeder payments may be negative, e.g. in the case of poorly performing
or highly indirect legs. This is better than penalising the final leg.
This mode reduces the need to tune the feeder shares setting to the
current network.

The feeder share setting applies in the existing way for both modes.
@ldpl

This comment has been minimized.

Copy link
Contributor

ldpl commented Jan 14, 2020

Doesn't need an option IMO. If it works better just use it, not like anyone would miss an old algorithm. Those profits are virtual anyway.

@michicc

This comment has been minimized.

Copy link
Member

michicc commented Jan 14, 2020

Indeed, as the transfer payment only affects vehicle statistics and not the real company profits, a setting is superfluous.

Either it is better (by some metric) than current, then it can just replace it, or it is worse. And if it would be worse, adding it is pointless.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.