a signage mystery
Jul. 25th, 2017 03:00 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
cellioI-376, like many other highways, has those overhead digital signs that somebody updates with topical messages like "accident, right lane closed 1 mi" or "stadium parking exit 72A" or, when they've got nothing better to say, "buckle up -- it's the law". There are two of these signs on my commute that, in their default states, say "distance to downtown: N mi, M min". Which, while usually not especially helpful to me (I live five miles from downtown), is still more useful to me than seatbelt nags. (I always use seatbelts.)
This morning, while stopped in traffic near Oakland, I saw one of those signs update from "4 mi, 5 min" to "4 mi, 6 min". That was less inaccurate, but far from accurate -- I reached downtown about 25 minutes later. (This is all very unusual; two of three lanes were closed due to a bad accident. My commute is sometimes slow, but I don't remember the last time I was in stopped morning traffic.)
It got me wondering -- do the indicators on those signs update automatically based on sensor data or are they human-controlled? The fact that an update happened but didn't jump to a more-appropriate number makes me think that we're dealing with an automated system that only bumps one unit at a time. (I would hope that a human would have updated it to warn about the accident.)
Why would it be designed to only increment in single units? Or is it a bug? What are the inputs to these signs, anyway?
(no subject)
Date: 2017-07-25 08:14 pm (UTC)(no subject)
Date: 2017-07-26 01:29 am (UTC)Somewhere I saw a discussion of a software design (I don't know if anybody's implemented it) that would disable certain functions on a driver's phone, like texting. How would they hit only drivers and not passengers? Relative positions -- if you see a pair or trio or whatever of signals moving down the road, the one in the front left is the driver. But this doesn't handle the case where the driver isn't carrying a phone but a passenger is; GPS just isn't that precise in my experience. So it'd be pretty annoying for the passenger to lose the ability to text someone to say they're running late...
(If GPS is that precise, then why the heck can't mapping apps tell me where exactly I am when I'm trying to navigate an unfamiliar area on foot? In Rome it often couldn't even correctly indicate which direction we were facing -- we'd be at an intersection with no street signs, walk in the direction consistent with the arrow, and after half a block the dot would move and show we'd taken a wrong turn so we'd have to undo it.)
(no subject)
Date: 2017-07-26 10:59 am (UTC)GPS can't help except by noting that the phone is moving at a speed consistent with a vehicle, faster than a pedestrian.
(no subject)
Date: 2017-07-26 12:57 pm (UTC)This seems like the sort of application that would be pushed by insurance companies and law enforcement, not something drivers would voluntarily choose.
GPS can't help except by noting that the phone is moving at a speed consistent with a vehicle, faster than a pedestrian.
It needs the speed information, but GPS plus other phones' GPS, and GPS plus map data, seems relevant?
(no subject)
Date: 2017-07-26 01:11 pm (UTC)People use BT in their cars primarily for listening to music from the phone over the car's audio system, and secondarily for using the car's audio system for phone calls.
GPS plus other phones' GPS, and GPS plus map data, seems relevant?
Only if you are Big Brother tracking all the phones over an internet connection. Remember, GPS is a one-way radio signal from satellits not dependent on the Internet; any time you think "GPS tracker" you are thinking about an integrated system with map data, mobile data connections and active processing.
E.g. you could build something like that, and GPS would be part of the solution, but you can't do it all on a single phone no matter how smart it is. The phone knows how fast it is moving by knowing the time and a series of position updates; it might or might not have an accelerometer and a compass. It doesn't talk to other random phones in the area to find out if they are moving at the same speed, and if it did, every car in a traffic jam would be difficult to distinguish from the others...
(no subject)
Date: 2017-07-27 12:54 pm (UTC)(State Farm just offered me a whopping 5% discount if I'd install and run their app. Er, no. A price might exist (it did, it turns out, for health insurance -- share this data to avoid a surcharge), but if so it's a lot higher than 5% of my modest auto-insurance bill.)
(no subject)
Date: 2017-07-26 12:37 pm (UTC)Also, there are many spots where GPS doesn't work as well--it is, after all, relying on Signals From Spaaaaaace that can get blocked by buildings, other signals, weather, or nearby military installations...
(no subject)
Date: 2017-07-26 01:01 pm (UTC)Also, there are many spots where GPS doesn't work as well
Right. I occasionally use navigation when going somewhere after work, and I turn it on in the parking garage because I don't want to be fiddling with my phone while driving, and I'm used to getting weird or no directions until I'm on the street. There's also a stretch of a few blocks where it often cuts out because of tall buildings. Maybe the hills in Rome were a problem? (Not tall buildings, at least where we were.) Or maybe ancient gladiator ghosts think we moderns are soft and they're disrupting the signals. :-)
(no subject)
Date: 2017-07-26 11:33 am (UTC)Cell phone location traces are also used to convert addresses to locations. For example, an indoor shopping mall typically has one street address, but lots of entrances, some of which are loading docks. Fortunately, loading docks and public entrances have very different cell phone location signatures, so we can tell which is which.
Cell phone location traces can also tell us that there's something new on the map that wasn't there last month -- a new housing development, a new road, a new business, etc. -- prompting further investigation, e.g. a StreetView vehicle going there to get photographs. The photographs can then be automatically analyzed to determine (in conjunction with cell phone data and volunteer user contributions) what the new thing is.
All of which is one of the reasons Google developed its own phone operating system. I can only assume Apple Maps is doing the same things with iPhone location data.
(no subject)
Date: 2017-07-26 01:04 pm (UTC)(no subject)
Date: 2017-07-27 04:22 am (UTC)Conveniently, many of the people in developing nations skipped the whole land-line thing and went straight to cell phones, albeit perhaps one per village, so we actually have data for places like sub-Saharan Africa.
Sending StreetView cars to sub-Saharan Africa is indeed expensive (although we've got StreetView kayaks, and StreetView backpacks, and there's now annotated StreetView of the International Space Station. Not sure about StreetView camels.) And we can work with satellite imagery when StreetView is too expensive.
(no subject)
Date: 2017-07-27 12:58 pm (UTC)and there's now annotated StreetView of the International Space Station
*blink* And so there is -- cool!
(no subject)
Date: 2017-07-29 06:28 pm (UTC)(no subject)
Date: 2017-08-01 02:16 am (UTC)The roads have been there for a while. Several years ago the main road to Cooper's Lake was closed (they were widening the formerly-one-lane bridge) and there was a back way in and out. On the way out I used my phone to help with navigation, expecting it to show me in an unmarked patch at first. Nope -- it said I was on Cariadoc's Path. And I was.
(no subject)
Date: 2017-07-26 12:44 pm (UTC)That is...a bit of a jump in inductive reasoning. The systems have seemed to me to be very sluggish in updating, which makes me wonder if they're time-delayed. It's possible the sign subsequently changed to 25 minutes shortly after you passed it.
The ones around here, when they're not saying "USE YA BLINKAH!", are often hopelessly optimistic--I wonder if they're programmed to make people feel good about the traffic ahead, rather than provide accurate data. (And if you do notice the discrepancy, you get mad at the sign, not at your fellow drivers.) But this seems far to clever.
(no subject)
Date: 2017-07-26 01:07 pm (UTC)(no subject)
Date: 2017-07-26 10:36 pm (UTC)(no subject)
Date: 2017-07-27 01:00 pm (UTC)Predicting the future is hard
Date: 2017-07-27 10:00 am (UTC)Predicting the future is hard, and all ETAs are inherently predictions of the future, with a lower bound set by various hard constraints but essentially no upper bound, because you never know what might happen between now and whatever even you're predicting the time of. Disruptions, such as an accident that blocks up the road, are especially troublesome because a) the time to clear the blockage may be dependent on too many exogenous and initially unknown factors to be reliably predictable with any useful precision, while b) that's when users especially want to see a prediction with useful precision, so they can make effective routing decisions. Whether there's a human in the loop or not, taking into account that there's a disruption and applying that knowledge to ETAs is a hard problem.
I would guess that the predicted ETAs on the variable message signs (VMS) are driven by automatic systems and not dependent on human input. Most likely, they are based on real-time measurements of actual speeds, flows, and possibly travel times (possible technologies discussed below). Those measurements are going to vary continuously, and changes in them will tend to lag the more discontinuous events marking the start and end of a disruption. So, an automatic system calculating ETAs based on them, especially if there's some smoothing algorithm to prevent momentary outliers from messing with the final numbers, will produce ETAs that creep up continuously after a disruption starts and then down continuously after a disruption ends, almost definitely more slowly than an educated human observer's guesses might change in light of knowledge of the disruption itself.
Technologies I'm aware of for automatic detection of traffic conditions:
- Induction loop detectors: These have been around for a long time. There's a rectangular loop of metal embedded in the road. Vehicles going over it induce a current, which is picked up by a sensor connected to the loop. It's possible to infer from that current turning on and off how many vehicles pass by in a given time and how fast they are going.
- Traffic flow cameras: Visual pattern recognition is good enough these days, I think, that computers can look at a traffic camera feed and determine flow and speed.
- License plate tracking for travel times: A camera at point A picks up when a particular license plate passed by, and then a camera at point B picks up the same license plate some minutes later, providing for a calculation of that vehicle's travel time. Do that across all the vehicles that go by, and you have live, real travel time data. There are, of course, civil liberties concerns with recording everyone's license plates, but I think they tend to implement such technologies with automatic dumping of the ID data. The thing about this is that while it gives you the exact units you'd use as an ETA, the measurement lags changes in conditions even more than point flow and point speed do, since you don't get a measurement of travel time from A to B until a vehicle completes that whole trip.
- EZPass tracking for travel times: Same idea as license plate tracking, except that you don't have to do image processing to identify individual vehicles; they identify themselves using RFID tags. Of course, this can only be used on EZPass-enabled toll roads, and the data may be biased by the fact that it only captures EZPass users.
Re: Predicting the future is hard
Date: 2017-07-27 01:05 pm (UTC)Is "why are the signs wrong" a FAQ in your industry? (For light rail/subway systems I assumed that they mostly weren't wrong, barring train failures -- limited access and you know exactly where the trains are right now -- but I haven't used such systems enough to have meaningful experiences.)
Re: Predicting the future is hard
Date: 2017-07-27 01:39 pm (UTC)The nature of disruptions on rail is indeed different. You don't have nearly as much volume-based congestion, since every vehicle out there is, at least in theory, there because a schedule said it should be. (However, at junction points, where trains have to take turns going through, they can experience non-linear congestion effects if they're on high-frequency lines and even one falls behind schedule.) So, absent disruption, the travel times are generally less variable than those on the roads. On the other hand, when a single train breaks down, has accommodate a sick passenger, or has to stop for any other reason, nothing's getting by without crossing over onto the opposite tracks, resulting in significant, difficult-to-predict disruption in both directions.
Re: Predicting the future is hard
Date: 2017-07-28 02:27 pm (UTC)I think they also use the data to determine whether or not to permit driving on the shoulder lanes (which are normally rush-hour only, but do get opened up at other times).
Re: Predicting the future is hard
Date: 2017-07-28 02:53 pm (UTC)