Split conversation from the UROverview Plus thread…
Actually, Waze have said that they keep a record of previous segment IDs, so a closure will still be in place even if the segment has been split. This seems contradictory to what Waze said to you.
I’ll see if I can track down the request from Waze, but I believe there was a directive not to disconnect segments after reporting a closure. If they are edited before reporting the closure, the closure won’t take effect till a role update goes through. If I find the original from staff I will quote it here.
Disconnecting segments won’t change their IDs, so it shouldn’t affect the closures. That said, it doesn’t make sense to disconnect the segment if it’s being closed via a sheet.
If a segment is ID changed and is then closed via the sheet, it won’t get properly closed until the map updates, which fits with what Waze says. Modifying the IDs after the closure is reported should be okay.
On the guidelines sheet of the Closures - USA spread sheet the following is listed as a requirement:
Who wrote the guidelines for the USA? One of the advantages of the closures system is that it preserves the state of the map. Having to then lock segments rather defeats that purpose.
I’ll see if I can track down a reference to what I said…
Meanwhile, I’ve split this conversation into a new thread. I couldn’t find a suitable forum where all the participants could read it, so I left it in Addons, Extensions, and Scripts.
Features is supplied the original segment ID on operations that would cause the segment ID to change, this is primarily for things like historical speed data and house numbers to get split and assigned properly.
Other than deliberately trying to break a closure via ID changes, we have no way of knowing for sure if Features properly updates closure information as well. This is only because in the past what Waze has said has differed from how something actually is for any number of reasons.
I propose we set up a test closure on test roads, and then try to break it by A) changing some segment IDs, and B) changing other junction IDs, and see what happens. If others agree I’ll set it up.
PesachZ: have you tested this yet?
If not, I’m happy to submit a closure in our sheet up here to see what happens.
I created test roads to use, was waiting for them to go live, just did yesterday I think. And now have to submit them for closure, wait for closure to go live, then test.
Bump…
Any update?
Yes. Sorry for the delay, I’ve been doing several things at once. So far I tested closure routing and documented the results to update the guidelines. I just made some more changes to the segments and reported another closure, after it gets uploaded, we’ll see how they were affected by the changes.
I added a junction to a segment adjacent to an existing closed segment.
I reported segment closed and then added a junction to the segment before the tile updated.
I added a junction in middle of a segment already closed.
Let’s see what these affects are… To be continued
Sent using Tapatalk for Android 4.4.2
Sorry for delay everyone. The results Ive found are
If you add a new node to a closed segment, you effectively changed the node id, and no longer have a segment between the two nodes it was previously.
(If segment 123 is between nodes 4, & 5. But you split it in half you now have one shorter segment between nodes 4, & 6. And another shorter segment between nodes 6, & 5. 6 is the new node in the middle. The shorter segments now also have new IDs.)
This breaks the closure whether you did it before or after the closure went live.
don’t do anything which changes the ID of the closed segments, or their nodes. it doesn’t matter when.
Changing the adjacent segments which connect to closed segments but aren’t closed didn’t have any effect.
Sent using Tapatalk for Android 4.4.2