Get a sneak peek at whats next for Permanent Hazards on our April 7th Office Hours!

Post Reply

Replace RTC removed by auto-generated City UR?

Post by APettyJ
Hello everyone!

Today I found a recently generated, as in the last day or two, [NOTE] UR generated by the City of Philadelphia, pertaining to a long-term water main project near me while making edits. I had submitted an RTC sheet that had been implemented by voludu2. That RTC no longer shows, and it was not scheduled to expire until sometime in September, so I am guessing when the UR was generated the closure was removed.

The reason I submitted the closure sheet is becreporause the area can be a traffic mess when the streets are shut down, which is pretty much every week day. As the UR and the Water Dept source I used to submit the closure indicates, the schedule for street closures may differ from week to week, and so it advises users to submit closures through the app. That does little good for any user of Waze, since they would already be in the mess when they would be able to report the closure, nevermind client-reported closures seem to rarely actually become "legit" closures as they aren't reported by other Wazers, at least in my neck of the woods. With the RTC ability to be temporarily disabled when traffic is detected on it, I thought it would be effective in helping to keep Wazers happy on their way, while alleviating some of the traffic woes in the area.

Can the closures be re-entered, or is this a situation similar to attempting to edit places added to Waze by an advertising business? If the RTC's can be re-entered, should they? Anecdotally, I can add that in the times I've been in the area while the closures were active, it seemed there were a couple instances where roads were showing as "closed", but were open to traffic, as well as a couple instances where roads were closed, that I knew I had submitted for closure, but on a particular day were clear in the app. One in particular was interesting because the road is completely blocked off on one end, so no traffic could have crept in,as is often the case with other closed sections. Maybe a higher than usual number of Wazers live on the block and exited that day via the open end of the block, causing the closure to become disabled! IOW, for the most part, roads showimg as closed in the app are actually closed during the times given.
APettyJ
Posts: 190
Has thanked: 56 times
Been thanked: 24 times

POSTER_ID:17123786

1

Send a message
WME L3: Junior Editor
App Beta Tester Waze v 4.22.1.901
Sprint
Samsung Galaxy Note 5
Android 7.0
Philadelphia, PA, USA

Post by APettyJ
clubjuggle wrote:I'm an active editor in New York City so I feel your pain, but I'm not sure what your proposing would work.

Are the streets you want to show as closed in the app actually closed real life? If not, then trying to second-guess Waze by reporting closures that actually exist is likely to do more harm than good. Consider for example the impact on someone trying to navigate to a street which shows as closed in Waze, but which is open in real life. Then, there's also the possibility of users in the area seeng persistent closures in the app on streets which are actually open, and losing confidence in Waze's ability to route them based on accurate information.

A UR shouldn't remove a closure, but traffic moving through the closed segments usually will (the exception is if traffic sensitivity is turned off). If you reported segments as closed which were actually opened, then Waze's traffic sensitivity did its job by removing the erroneous closures.
It's a long-term project spanning a lengthy portion of the roadway. It would be helpful if I did add a PL, wouldn't it?

https://www.waze.com/livemap?lon=-75.09 ... 72&zoom=17

That's a LM PL to the site. Frankford Ave, from the creek to Castor Ave. The portion between Castor and Glenwood Ave, as well as Pike Street to Jasper St/Hunting Park Ave is typically closed every day. Castor to Glenwood is blocked completely at Castor, so no thru traffic is possible, although residents on the block may exit during construction times via the intersection at Glenwood Ave.

Voludu2 had put a RTC on the entire segment, set to disable if traffic was detected. I replied to the UR I mentioned, which I have since learned was not auto-generated although I am unable to see who left it, and they said another UR had been left stating the roadway showed as closed in Waze but was in fact open. IMO, that is ideal. Frankford Ave, during the course of this project, should not necessarily be used as a thruway, unless Waze detects traffic indicating a particular segment is in fact open. Not marking the roadway closed allows Wazers to be routed into the area. Of course, they'll see the roadway closed and use an alternate street in the area. Problem is, those alternates will be jammed. If Frankford is marked closed and traffic is detected on the alternates, Wazers who are not traveling to that area will be routed elsewhere. Since Frankford isn't marked closed, and the closed section will show minimal to no traffic on it, well, you may see the problem.

Frankford Ave is classed as a PS, not long ago reduced from a mH, so traffic will be routed onto it. At the very least, Frankford Ave from Pike St to Jasper St/Hunting Park Ave as well as Castor Ave to Glenwood Ave should get the closures, set to disable if traffic is detected. In the future, if someone does make a UR mentioning that the road is in fact open, verify that they can confirm the road is open more permanently; someone who just happens to drive through that area on a day they are not working the section may not be around in a couple days when the section is shut down again, and they may not deal with the excessive traffic on Jasper, Castor or Glenwood (Castor Ave is just an ugly roadway everyday, period, but this project doesn't help).
APettyJ
Posts: 190
Has thanked: 56 times
Been thanked: 24 times
Send a message
WME L3: Junior Editor
App Beta Tester Waze v 4.22.1.901
Sprint
Samsung Galaxy Note 5
Android 7.0
Philadelphia, PA, USA

Post by APettyJ
In the future it may be better to ask for updates before removing the closures. A CM had implemented the closures, and appeared to not be aware of the removal when I asked them about it. In addition, unless you are prone to drive these particular roads, you may not be aware of the problems caused by not allowing the temporary disabling of closures by detected traffic as it is designed to do, rather than wait for closure reports that may or may not come in, and are often not acted upon, that is, made into route-affect RTC's even if submitted via the client app. URs reported in the area can always be replied to by stating why the roadway is showing as closed, along with the reminder that their driving on the segment that day showed to Waze that it was open.

If in my travels of the area I see that the roads are being regularly closed again, I may re-submit the RTC. This project is supposed to continue into 2017, and in talking to local residents and business owners, they have been told to expect major delays on area in the coming months.
APettyJ
Posts: 190
Has thanked: 56 times
Been thanked: 24 times
Send a message
WME L3: Junior Editor
App Beta Tester Waze v 4.22.1.901
Sprint
Samsung Galaxy Note 5
Android 7.0
Philadelphia, PA, USA

Post by APettyJ
Yes, I was under the impression it would be suspended for that day, and would start anew the next day.

Since this conversation began, it has made me appreciate the need for some type of 'closure response team', or something. The ability to have Livemap closures seen in WME means we should be able to catch when roads are closed by projects, particularly in areas where we know of a project happening. So, for example if you saw a closure entered on a section of Frankford Ave today, using the previously acquired info from the city you could set a traffic-sensitive RTC, set to expire at the end of the construction work day (3:30 for Frankford project). Erik had already done something similar when a block of Cherry St was closed several weeks ago, at least in that a map from the city showing blocks where permits to partially or fully close the block had been acquired. Erik had deduced a crane for a bldg project was probably the reason for the closure. It occurs to me this is probably the best way to use resources like this for the city, except who really has the time to spot app closures this way? Hence, the thought of a 'team'. I wouldn't be available, though.

Sent from my SM-N920P using Tapatalk
APettyJ
Posts: 190
Has thanked: 56 times
Been thanked: 24 times
Send a message
WME L3: Junior Editor
App Beta Tester Waze v 4.22.1.901
Sprint
Samsung Galaxy Note 5
Android 7.0
Philadelphia, PA, USA

Post by clubjuggle
I'm an active editor in New York City so I feel your pain, but I'm not sure what your proposing would work.

Are the streets you want to show as closed in the app actually closed real life? If not, then trying to second-guess Waze by reporting closures that actually exist is likely to do more harm than good. Consider for example the impact on someone trying to navigate to a street which shows as closed in Waze, but which is open in real life. Then, there's also the possibility of users in the area seeng persistent closures in the app on streets which are actually open, and losing confidence in Waze's ability to route them based on accurate information.

A UR shouldn't remove a closure, but traffic moving through the closed segments usually will (the exception is if traffic sensitivity is turned off). If you reported segments as closed which were actually opened, then Waze's traffic sensitivity did its job by removing the erroneous closures.
clubjuggle
Posts: 193
Has thanked: 38 times
Been thanked: 30 times
Send a message

Post by clubjuggle
APettyJ wrote:In addition, unless you are prone to drive these particular roads, you may not be aware of the problems caused by not allowing the temporary disabling of closures by detected traffic as it is designed to do, rather than wait for closure reports that may or may not come in, and are often not acted upon, that is, made into route-affect RTC's even if submitted via the client app.
Unless I misread your post, you may be misunderstanding the way that traffic-sensing works on a real-time closure.

Traffic-sensing does not allow for a closure to turn itself off and back on again depending on whether traffic is or is not detected at the moment. Rather, it provides a mechanism for a closure to expire (delete itself) early if traffic is detected prior to the scheduled expiration. This is handy if a construction project finishes early, or when a closure is placed for an accident or other emergency and it is not clear when the closure should end.

In other words, a closure set with traffic sensitivity will expire at the scheduled expiration time, or when traffic is detected, whichever comes first. Either of those events causes the closure to expire entirely, not just to suspend itself and put itself back later. Once either of those events expires the closure, it's gone, and if the road closes again, a new closure needs to be set.

Apologies if that's how you understood it (and if my explanation was therefore unnecessary), but based on your last couple posts it looked to me like you might have been under the impression that traffic sensing suspends a closure rather than expiring it.
clubjuggle
Posts: 193
Has thanked: 38 times
Been thanked: 30 times
Send a message

Post by DrNeubie
Alan,

Do you have a PL to the area? If you know the times of the closures, then entering them as RTCs would be the best solution to this situation. A UR cannot remove an RTC, it may have expired. Do you know who placed the original UR? The sheets are no longer being checked regularly by Waze staff -- this was part of the impetus behind the expanded editor access to RTCs.

So that's the good news -- since R3 editors can now place RTCs, you can address this issue directly. If you know the hours that the road is supposed to be closed, place the RTCs and they will turn off if Waze detects traffic flow in the area.

If you have any questions or need help with this don't hesitate to let me know.

Dave
DrNeubie
Posts: 218
Has thanked: 116 times
Been thanked: 109 times
Send a message

Post by unlimited1808
I removed the RTCs. We had UR(s) reporting Frankford was open. I think I left the UR and pasted the information from the Philly Water Dept's website.

When I checked the construction information, it clearly noted the streets *may* be closed, not *will* be closed. To schedule the entire length of Frankford as closed every day from 0700-1500 is inappropriate and not useful to Wazers when the road is likely open more often than it is closed.

Rarely is the entire length of roadway closed for the whole project either. These projects often progress a couple blocks at a time. Closing the length for the entire project is inappropriate.

I'm not opposed to closures here if we can find a better schedule of when they'll be working and where to be more precise with our closures. Otherwise, if the closures are random and sporadic, we are more limited in our options and should leave it to users to daily closure and allow Waze to do it's job.
unlimited1808
Posts: 295
Has thanked: 63 times
Been thanked: 83 times
Send a message

Post by voludu2
When in doubt, leave it out.

The problem with a 24/7 RTC on a road that is open most of the time is it is, most of the time, routing wazers around a perfectly usable route, especially during lower-traffic times of day.

The problem with no RTC at all is that in-app closures are rarely deceive for anyone but the person entering them.


It seems we don't have enough information to know which is worse

When I first entered that closure, I thought it seemed similar to another closure I had done where I had info from someone on the project who had specific information.

Unfortunately, editing rank does not confer local insight. If we had specific information from someone on the project on future closures, it might be possible to put on a closure that does more good than harm.
voludu2
Posts: 3098
Has thanked: 559 times
Been thanked: 863 times
Send a message

Post by voludu2
I have it on good authority that traffic passing through an RTC can cause a TEMPORARY suspension of the closure, rather than an automatic early expiration of the RTC.

If "enough" waze traffic passes through during a "sufficient" period of time, then waze routing stops applying the penalty.

After "a while" the traffic is evaluated again. If there is "no traffic" for a "sufficient" period of time, the RTC penalty is reinstated.

Waze team does not tell us about the size of the quantities on quotation marks (how long, how much traffic...) The wiki page for RTC really should cover this.
voludu2
Posts: 3098
Has thanked: 559 times
Been thanked: 863 times
Send a message