by ewerninghaus » Wed Apr 17, 2013 3:22 pm
Hello,
I also miss the variable time to vanishing of hazard warnings... Potholes= long time ... police=short time. And the likes / not exists could keep it active or kill it. That should not be a tough job to implement in the algorithm. Create something like a "expected lifetime" variable at each hazard communication (I believe this is already in place within the code).
The algorithm shall be robust enough to:
1 - do not keep the hazard "forever" because of hundreds of likes (like a police stop at a high traffic area). So a sum-up or a multiply system won't work well.
2 - do not kill the hazard too soon because nobody drove through it soon enough.
3 - do not vanish with the first "does not exist", but with a few "does not exist" go away fast enough (i.e. we cheer our leaders who finally fixed the potholes =:) or I still want that police stop alert, although a few morons reported it as non-existing because the policeman was not standing near it's vehicle.)
4 - prevent us from needing to retype the hazard daily (in case of road constructions, potholes, etc). Seriously, if it would stay longer I would take the effort to stop the car, get a good picture of the pothole and include it in the report. But not in a daily (hourly) basis to vanish few minutes later.
So my humble suggestion would be:
Every type of hazard has it´s own original latency : potholes and road constructions 3 or 4 days (enough to bridge an extended weekend), while police and weather would last for 1/2h or 1 hour.
Every "like" extends the lifetime like if it would be freshly reported (postponing the "expected lifetime"); every "doesn't exist" takes 50% of the remaining lifetime.
example1 : Pothole (3 days original latency) reported on the 5th of the month -> scheduled to be erased on the 8th (+3Days); likes on the 6, 7, 9, 11, 12, 13, 15th -> erase on the 18th; 1 doesn't exist on the 15th -> erase on the 16,5th; another doesn't exist on the 16th -> erase on the 0,25th (it was 0,5 left)
example2 : Police (1h original latency) reported at 14:00h -> scheduled to be erase at 15:00h (+1Hour); Hundreds of likes received until 17:00h -> erase at 18:00h; first doesn't exist at 17:14h -> erase at 17:37h (there were 46 minutes left, now only 23); second doesn't exist at 17:17h -> erase at 17:27h; third doesn't exist at 17:21h -> erase at 17:24h.
I hope this humble opinion helps the Waze software engineers to make our life better.
What do you think about it?
Best Regards
Edy