[traffic] Handle removed segments or eased traffic impact

Signed-off-by: mvglasow <michael -at- vonglasow.com>
This commit is contained in:
mvglasow
2025-06-15 20:42:48 +03:00
parent f31541efb2
commit 26aa5e5f54
4 changed files with 41 additions and 5 deletions

View File

@@ -518,9 +518,18 @@ void TrafficManager::DecodeFirstMessage()
// store message in cache
m_messageCache.insert_or_assign(message.m_id, message);
}
// store message coloring in AllMwmColoring
// TODO trigger full cache processing if segments were removed or traffic has eased
traffxml::MergeMultiMwmColoring(message.m_decoded, m_allMwmColoring);
/*
* TODO detect if we can do a quick update:
* - new message which does not replace any existing message
* - coloring “wins” over replaced message:
* - contains all the segments of the previous message (always true when location is the same)
* - speed groups are the same or lower as in previous message (always true when all members of
* traffic impact are unchanged or have worsened) for this purpose, closure is considered
* lower than any other speed group
* In this case, run:
* traffxml::MergeMultiMwmColoring(message.m_decoded, m_allMwmColoring);
* Otherwise, set a flag indicating we need to process coloring in full.
*/
}
void TrafficManager::ThreadRoutine()
@@ -779,6 +788,20 @@ void TrafficManager::OnTrafficDataUpdate()
LOG(LINFO, ("Announcing traffic update, notifyDrape:", notifyDrape, "notifyObserver:", notifyObserver));
/*
* TODO introduce a flag to indicate we need to fully reprocess coloring, skip if it is false.
* The flag would get set when messages get deleted (including any clear/purge operations),
* or when a new message is added without indicating a simplified update in `DecodeFirstMessage()`.
* When we reprocess coloring in full (the block below), reset this flag.
*/
{
std::lock_guard<std::mutex> lock(m_mutex);
m_allMwmColoring.clear();
for (const auto & [id, message] : m_messageCache)
traffxml::MergeMultiMwmColoring(message.m_decoded, m_allMwmColoring);
}
/*
* Much of this code is copied and pasted together from old MWM code, with some minor adaptations:
*
@@ -819,6 +842,15 @@ void TrafficManager::OnTrafficDataUpdate()
UpdateState();
/*
* TODO BUG: this leaves behind deleted segments
* If an update removes segments (but the MWM still has segments), some (the first added?)
* may be left behind but will disappear on the next update. This has been observed with
* TraFF Assessment Tool when updating a message with another one resulting in fewer
* segments. Unclear if routing is also affected. The number of segments in the affected
* MWM does not change between the botched and the working update, indicating the correct
* coloring was passed and the problem is on the receiving end.
*/
if (notifyDrape)
{
m_drapeEngine.SafeCall(&df::DrapeEngine::UpdateTraffic,

View File

@@ -394,6 +394,10 @@ private:
* @brief Processes new traffic data.
*
* The new per-MWM colorings (preprocessed traffic information) are taken from `m_allMmColoring`.
* `m_allMwmColoring` is rebuilt from per-message colorings in `m_messageCache` as needed.
*
* This method is normally called from the traffic worker thread. Test tools may also call it from
* other threads.
*/
void OnTrafficDataUpdate();

View File

@@ -289,7 +289,7 @@ void TraffMessage::ShiftTimestamps()
m_endTime.value().Shift(nowRef);
}
void MergeMultiMwmColoring(MultiMwmColoring & delta, MultiMwmColoring & target)
void MergeMultiMwmColoring(const MultiMwmColoring & delta, MultiMwmColoring & target)
{
// for each mwm in delta
for (auto [mwmId, coloring] : delta)

View File

@@ -450,7 +450,7 @@ using TraffFeed = std::vector<TraffMessage>;
* @param delta Contains the entries to be added.
* @param target Receives the added entries.
*/
void MergeMultiMwmColoring(MultiMwmColoring &delta, MultiMwmColoring & target);
void MergeMultiMwmColoring(const MultiMwmColoring & delta, MultiMwmColoring & target);
std::string DebugPrint(IsoTime time);
std::string DebugPrint(Directionality directionality);