Do you mean like if the closure on a small part of a much longer segment with maybe like houses along it? I thought of this actually but figured since closures go down independently of map edit builds, and breaking the segment up to isolate the specific closure would involve map edits, it could potentially create a conflict or end up closing the wrong segment do ending on how segment numbers are assigned during such a split. So I figure it’s probably just better to isolate the smallest accurate set of existing 1 or 2 segments to submit as closed.
That’s what I understood punrum to be advocating.
Per Waze I added two new tab to the sheet. Please take a look at it. I also updated the guidelines as well. If there is any questions, please let me know.
Thanks! I was wondering how that column was going to work when I saw it on the submission sheet.
This form has a field “time zone – pick from list”. But there is no list to pick from.
I just typed in EDT. I hope that is OK.
Original post updated.
Should the list of node IDs be separated/delimited by commas, spaces, or doesn’t it matter and I’m just too obsessive about these sorts of details? :geek:
Yes. :lol:
Does this mean we should update the advice in
https://wiki.waze.com/wiki/Road_names/USA#Construction_zones_and_closed_roads
to do short- and medium-term road closures this way instead of relying on wazers driving by daily or changing the road’s name?
I noticed that the closure guidelines were updated to advise us to close crossing segments (where appropriate). The guidelines depict closing the input segments, but I was wondering if it would make more sense to close the output segments instead?
In the example provided, it is likely that local traffic would be allowed to access the highlighted (closed) cross-street segments (the inbound portions of 10th, 11th, and 12th streets). Wouldn’t it make more sense to close the opposite (outbound) segments instead, since local traffic would not be able to access these segments?
I had posted some notes about this issue here after working with WazeHQ on a major event in Manhattan and dealing with blocking cross streets.
An example of blocking outbound streets rather than inbound streets here. This includes an allowed crossing at 79th st and a disallowed 2-way crossing at 86th st
Following guidance here:
I had submitted an update request to open the PL’ed segments here on August 22. This was based on a UR report and my own driving down these segments to confirm.
I think I initially had the closure ending 2014-08-31. Should this expire on its own or should there be an update to remove the closure?
Yes and no.
I’ve noticed that closures sent via this form stop showing as closed on the app at the date and time specified.
However, it seems to generate a UR with a description starting with “[ROADWORKS]” i[/i]. The UR does not remove itself automatically. Observing the actions of my RC with respect to these URs, I’ve started marking them as “Solved” once the closure expires.
If the closure is no longer active, it should be removed once it is confirmed, assuming it opened back up earlier than the expiration date. If it is set to close as scheduled, no further action is required, it will expire per the schedule.
If the RC/CM/SM that inputted the closure also opened up a [ROADWORKS] or [CLOSURE] UR at that location, you can post a note to that indicating that you have requested it be reopened ahead of schedule. The RC/CM/SM should close the UR out as solved once the closure has been removed.
Check in with the person who opened the UR before closing it. I normally don’t have a problem with expired URs being removed, but it might be good to check in first just in case they were leaving it as a place holder to check back in to make sure the closure actually opened back up at the time indicated. I have a few spots in CT where the end dates are approximate, and the UR pins are there as reminders to check back every now and then
As best I can tell, the URs do not get opened automatically (yet). I have to open them manually, but WazeHQ gave us a nifty text generator that pre-populates all the info so we just drop it in.
I agree. The guidelines should probably be changed.
I usually only code cross streets which lead away from the closure, if there’s a way to get to it besides the closure. Basically block people crossing over the closure, but not the streets which lead to the closure.
Sent using Tapatalk for Android 4.4.2
I don’t disagree either but this is what Waze told me to put in the guidelines. See images below.
I think, there are several issues here:
- This is a more of a bug or an issue within Waze. When We/Waze close a road, Waze app should be smart enough to know not to route over it or cross it.
- They need to be consistent when they are giving us the info. Obviously, both info we got from them are conflicting.
Orbit,
The example they gave is 5th Ave between form 13th to 9th Streets.
The problem with the advice is it doesn’t account for whether the intersections in the middle are actually closed, and it should be clearer about that. Sometimes, transverse traffic is allowed across a closed stretch of road, even though the road itself is closed. For example, say they were closing that stretch of 5th because they are laying new sewer pipe. They might bridge the three intersections shown so that 10th, 11th and 12th, even though hey cross right through the middle of the closed section of 5th, still allow traffic to flow from 6th Ave to University Pl (10th and 12th) or vice versa (11th). Because the more streets closed, the worse the traffic snarls up, and the more residents and businesses impacted. NYC DOT does this all the time.
In other situations, even 9th and 13th could be affected. If they had to close the entire length and could not bridge the intersections, they might also be fully or partially closing the two "end intersections.
Your statement is true, we only have to worry about cross streets, if through traffic across those intersections of blocked. However the discussion is when we have to close side streets, which side should we close. Orbit is getting confirmation from Waze on that.
Sent using Tapatalk for Android 4.4.2
Another issue with the approach recommended (in the case that we really do need to close the crossing streets) is how do people get routed to the businesses and/or residences along those closed segements of 10th, 11th, and 12th streets? Assuming only the intersection is closed, it seems like it would be better to either disconnect the side streets leaving oneself a [NOTE] UR to remember to reconnect after the closure or add nodes on either side of each intersection creating 5 m segments and close those segments as well. It’s more work for us, but what else is there for it until they make intersection blocking an optional part of the closure?
Don’t disconnect any roads unless they are physically not roads anymore. That’s the whole point of the closure system, so we no longer have to disconnect roads. Waze has asked us not to disconnect segments.
If the proposed change goes into effect, then people will be allowed to be navigate up until the closed intersection, but not across it, as the only segments actually closed would be one leading AWAY from the closure, which are inaccessible because you can’t drive through the intersection.
Sent using Tapatalk for Android 4.4.2
Upon closer inspection of the example I see the crossing streets are all one-way roads so the proposed change to close the outgoing segments makes a lot of sense. I was thinking in terms of two-way crossing segments. How are we supposed to close the intersections without closing the whole side-street? Should we just restrict all the turns and the straight through arrow?
I offer this permalink from my area as an example. Harbor Drive is closed as are the intersections at County St and King St.