Sometimes when working on large projects, it is difficult to get the timing with tile updates to make a major project (or even smaller projects) go live at the correct time. Often this is done with adding segment restrictions to new segments, waiting for a TU, then applying an RTC and removing the restriction, so that when it goes live, just the RTC has to be removed. However, this usually only works when what is added is totally new and doesn't require reuse or reconfiguring of previous segments. It is also very difficult during reconfigurations when the project all of a sudden changes over early, or has a last minute delay. If we don't catch it in time, it can require several tile updates to get WME correct, and then wait for it to go live in the app. This is frustrating for editors because it makes deadlines and sudden changes very difficult, and frustrating for drivers getting incorrect instructions.

My idea is a project mode that allows editors to work on large projects over several days without worrying about breaking routing, messing with current configurations, breaking RTC abilities, etc... all while keeping the behind-the-scenes mess hidden from the drivers using the app. Then, with a push of a button (or a predetermined time), the "project" can be made live in the app. Further details below on potential implementations to prevent concurrency issues while guaranteeing a great experience for editors and drivers.

1 - How to create a "project": An editor with the required rank (set by regional coordinator) selects the "Project" polygon in WME and then draws a polygon around segments that will be included in the project and gives it a name. I'll refer to this polygon as the project zone from now on. Segments inside the project zone can be any lock level, even higher than the editor that places the project zone. Segment lock restrictions function as normal. Project zones are visible on the map through a "Projects" layer. Any segment that is included in a project zone is flagged as being part of that project, and when selected, it will display which project zone it's a part of. At this point, this segment is locked from editing unless in project mode, similar to the RTC editing lock. A project zone can be expanded to include new segments, but if it's shrunk enough that a segment flagged as included is no longer included, you cannot save. The idea behind this "project zone" is to create a clone of the current status of WME so that changes done do not affect the current tile build.

2 - Working the project: Just like we can view the previous tile build, there will be an option to view the map as it is now, or view the "project". Any editor of any rank should be able to view the project progress, even if they can't create or modify it. From inside the project mode, you simply edit as normal to the new configuration saving often, not worrying about breaking routing (remember, the current map state is unaffected by this). Once editing is complete, including verifying routing is unbroken, you will "publish" the project to the map. I imagine that every time you save while in construction mode, a check that the edit is allowed and viable is made, but not actually completed. Then, when you publish, the edits are actually published to the map. At this point, even after a tile update, the old configuration is what is used in the app and for routing.

3 - Making the new configuration live: The previous "publish" button actually will have two options. Publish and keep hidden, or publish immediately. Publishing immediately applies all changes in the project zone to the map, and removes the project zone. It will be live after the next tile update. Publishing and keeping hidden will send all the segments in the next tile update but keep them hidden. How do you ask? Just like RTCs can immediately affect routing and affect the visual appearance, the published but hidden segments are kept invisible on the map and have an RTC applied so that traffic isn't routed on invisible segments. Then, an editor in WME can select the project zone and "switch configuration" on demand or schedule it. Upon switching this configuration, the new configuration goes live instantly in the app by making the new configuration visible without RTCs, and any old segment IDs that were not reused go invisible with RTCs. The project zone remains on the map for 2 weeks or until manually removed by an editor. The editor can switch back to the old configuration instantly if needed, such as with a delay in crossing over.

4 - In-app experience: Won't be snapped to incorrect segments that have been moved for a new configuration. Won't need to wait days for a configuration to go live in the app, especially in the event of a tile update delay. Able to take advantage of new configuration instantly.

5 - Benefits to editors: Able to work on big projects in chunks over time. Can start adding or changing something, save to verify that it's a valid change, and continue editing. All without worrying about breaking routing (whereas saving often normally might break routing, or require lots of extra steps). No longer need to cram a large project in between tile updates. No longer needing to hope you're available to make the change on the exact day so that the correct tile update makes it go live, but not too early or too late. You could theoretically work a change weeks in advance. Allows us to still RTC segments from the old configuration while working the project zone.

6 - Example scenarios:

6-1: This displaced left turn required lots of steps with time based segment restrictions set to have it open at the correct time. Due to weather, the city announced it was delaying opening it by 2-3 days. This was announced 20 minutes before a tile update that would have set the new configuration in motion. Luckily I was able to catch it and update several time based restrictions. Then, after it was live, I had to go in and clean up turn restrictions and lane guidance that was no longer needed or correct. With a project mode, all the changes would be done well in advance of it going live. Then, set the configuration to change at the correct time. If we spotted it was delayed, simply change the time and date. If we didn't, we could reverse the configuration since the project zone would still be there for up to two weeks after it was changed. https://www.waze.com/en-US/editor/?env=usa&lon=-98.07749&lat=29.72828&zoomLevel=19

6-2: US-281 is undergoing a major expansion. Editors could work to map new freeways and frontage roads (that are probably a few weeks to a few months from being done) now while keeping the current configuration for the drivers. Then, as soon as it goes live, we can easily switch it. Currently, if we get a heads up it's opening, we'll have to get it all done in one day and hope there are no delays crossing over. If we don't get a heads up, we'll still need to try to cram it into one day so we don't break routing. https://www.waze.com/en-US/editor/?env=usa&lon=-98.44717&lat=29.68590&zoomLevel=14&mapComments=171376937.1714097047.939091

6-3: Dividing roads. You can save often to verify that you won't receive an error while not worrying about breaking routing. No having to create bowties every few intersections to save. Simply divide as you want, saving with segments halfway complete as you cut and merge, and then once done, publish to map immediately.

6-4: Any other project that is time consuming where you don't want to complete it in one sitting.

7 - Closing thoughts: This is obviously a giant ask and would likely be very difficult to include. I've tried to suggest it to where concurrency with other edits won't be an issue because they'll be locked. This is a giant mental work-in-progress, so any improvements to the basic idea are more than welcome.