topic Road Closure Solution producing error in Waze in ArcGIS Solutions Questions

Road Closure Solution producing error in Waze

Jennifer_Parmeley — Fri, 12 Sep 2025 19:10:36 GMT

I deployed Road Closures for our organization so we could use RC schema to feed Waze. There's a push to use Waze in our area.

During testing I found an error in the Waze Partner space. The "Work Area" value is not accepted by Waze, it appears, but I'll be honest that reading an xsd is not something I have a great deal of experience doing. I'm not sure at this point if I should update the domain list in the ESRI solution (what else will this break?) or try to add the subtype information that Waze might be looking for. I had a support ticket with ESRI about the solution and they were very specific about schema changes and not making them. I've made several because we need them. I cannot 100% redesign our product for our smaller community, the change needs to happen more slowly. We are only using the feature service (and related view) in our local solution, so I don't care if the map and ExB part of the solution don't work, I've got my own solutions there, but I want Waze to get the data we are sending.

Has anyone else found this? Any suggestions on getting this to work? Maybe I'm missing something basic?!

Updating the feature to a "hazard" does not fix the error in Waze. Hazard is in the solution and Waze xsd.

part of the Waze xsd, with I think, the related info.

Re: Road Closure Solution producing error in Waze

Joshua-Young — Fri, 12 Sep 2025 22:29:44 GMT

Where did the value "Work Area" come from? We have been using version 2.0 of the Road Closure solution and the only types we have are Construction, Event, and Hazard. Esri changed the data schema from version 1.0 to 2.0 and it is no longer compliant with Waze's schema. The only automated way to use Esri's 2.0 solution and have a Waze Feed is to create another feature service with a schema that matches what Waze requires and then create a python script that translates the Esri data to the Waze schema. Then schedule the script to run at a specific interval.

I have not done this yet. Honestly, I have been putting it off hoping that Waze would become a partner with Esri's live feed. I still input the road closures into Esri's solution and then log into Waze's Partner Hub to add the same closures there.

Re: Road Closure Solution producing error in Waze

Jennifer_Parmeley — Sun, 14 Sep 2025 17:46:56 GMT

I think "Work Area" one of my testing values - so my mistake on the post.
It still doesn't make sense that Hazard doesn't work.

Re: Road Closure Solution producing error in Waze

Joshua-Young — Mon, 15 Sep 2025 13:59:16 GMT

I found an archive of the version 1.0 schema of the Road Closure solution in my files and have attached a copy showing how the data schema used to be setup to support Waze Feeds.

Waze is expecting a "type" field and a "subtype" field. The "type" field value for road closures is always ROAD_CLOSED, and the subtype field is going to be either ROAD_CLOSED_CONSTRUCTION, ROAD_CLOSED_EVENT, or ROAD_CLOSED_HAZARD. The values are all caps and underscores for spaces.

The version 2.0 of the Road Closure solution changed the "type" field to "reason", got rid of the subtype field, and changed the "reason" values to "Construction", "Event", or "Hazard". That is why Waze does not recognize the input anymore. If you want to use Esri and Waze while only editing one feature service, you will need a Python script that extracts, translates, and loads the data from the Esri format to the Waze format.

Re: Road Closure Solution producing error in Waze

Joshua-Young — Mon, 17 Nov 2025 15:52:43 GMT

@Jennifer_Parmeley this prompted me to finally work on a Python script to sync the v2.0 schema with the v1.0 schema. This may not be the most optimal way to do this, but here is the Python script we are now using. The script takes the v2.0 service and translates the data to match the v1.0 service. Then it compares the content of the v2.0 service to that of the v1.0 service to see if an update is needed. If the data matches the script exits, but if there is a difference then the v1.0 service is truncated and the new data is added.

For all of this to work the v1.0 service needs to have supportsApplyEditsWithGlobalIds set to True and Sync cannot be enabled on the service. The GlobalID setting is needed to copy the GlobalIDs from v2.0 to v1.0 otherwise new GlobalID are created. The GlobalIDs are needed for the comparison. Sync must be disabled or the truncate operation will fail.

I am running this on ArcGIS Enterprise using ArcGIS Notebook Server Standard, but it should work with ArcGIS Online and/or a standalone Python file running as a scheduled task with some adjustments to the code.

from arcgis.gis import GIS from arcgis.features import GeoAccessor import pandas as pd import numpy as np gis = GIS("home") # Get the Esri road closures layer using its Item ID item_esri_closures = gis.content.get('<InsertEsriItemIDHere>') # Get just the closure lines layer from the Esri road closure item layer_esri_closures = item_esri_closures.layers[1] # Convert the feature layer to a spatial Pandas dataframe sdf_esri = GeoAccessor.from_layer(layer_esri_closures) # Create a column to store the Waze "type" value and default it to ROAD_CLOSED sdf_esri['type'] = 'ROAD_CLOSED' # Create a column to store the Waze "reference" value and default it to organization ID sdf_esri['reference'] = '<InsertWazeOrganizationIDHere>' # Replace the Esri "reason" values with the Waze equivalent sdf_esri['reason'] = sdf_esri['reason'].replace({'Construction':'ROAD_CLOSED_CONSTRUCTION', 'Event':'ROAD_CLOSED_EVENT', 'Hazard':'ROAD_CLOSED_HAZARD'}) # Replace the Esri "direction" values with the Waze equivalent sdf_esri['direction'] = sdf_esri['direction'].replace({'Both Directions':'BOTH_DIRECTIONS','One Direction':'ONE_DIRECTION'}) # Rename Esri columns to match Waze column names sdf_esri = sdf_esri.rename(columns={'reason':'subtype', 'closureid':'identifier'}) # Keep only the columns that match the Waze schema sdf_esri = sdf_esri[['street','subtype','description','direction','altroute','pocname','pocemail', 'pocphone','url','identifier','activeincid','type','reference','globalid', 'created_user','last_edited_user','created_date','starttime','last_edited_date', 'endtime','SHAPE','SHAPE__Length','objectid']] # Get the Waze road closure service using its item ID item_waze_closures = gis.content.get('InsertWazeItemIDHere') # Create a feature layer object of the closure lines layer from the Waze road closure item layer_waze_closures = item_waze_closures.layers[0] # Convert the feature layer to a spatial dataframe sdf_waze = GeoAccessor.from_layer(layer_waze_closures) # Compare just a subset of the fields from both services # Apparently the SHAPE and SHAPE__Length are modified slightly when applying the edits # so they will not match compare_fields = ['street','subtype','description','direction','altroute','pocname','pocemail', 'pocphone','url','identifier','activeincid','type','reference','globalid', 'created_user','last_edited_user','created_date','starttime','last_edited_date', 'endtime'] sdf_waze_compare = sdf_waze[compare_fields] sdf_esri_compare = sdf_esri[compare_fields] # Make sure the null values are the same between the dataframes sdf_waze_compare = sdf_waze_compare.replace(np.nan,'') sdf_waze_compare = sdf_waze_compare.replace(np.nan,'') # Make sure the dataframes are sorted the same way using the GlobalID sdf_esri_sort = sdf_esri_compare.sort_values(by='globalid', ignore_index=True) sdf_waze_sort = sdf_waze_compare.sort_values(by='globalid', ignore_index=True) # Set the index of both dataframes to use the GlobalID sdf_esri_sort = sdf_esri_sort.set_index('globalid') sdf_waze_sort = sdf_waze_sort.set_index('globalid') # Check if the number of rows are the same equal_indexes = sdf_esri_sort.index.equals(sdf_waze_sort.index) print('Row Count Equal: ' + str(equal_indexes)) # Check if the number of columns are the same equal_columns = sdf_esri_sort.columns.equals(sdf_waze_sort.columns) print('Column Count Equal: ' + str(equal_columns)) # Check if the data in the dataframes already match exists = sdf_esri_sort.isin(sdf_waze_sort.to_dict(orient='list')).all(axis=1) equal_values = False if all(exists): print('Data Equal: True') equal_values = True else: print('Data Equal: False') equal_values = False # A list of the check values checks = [equal_indexes,equal_columns,equal_values] if all(checks): # If all the checks are True then everything is # exactly the same and nothing needs to be updated print('Nothing to update') else: # If one of the checks is False then update the Waze service # Convert the translated dataframe of the Esri service to a FeatureSet featureset_esri = sdf_esri.spatial.to_featureset() # Remove all existing rows from the Waze feature layer layer_waze_closures.manager.truncate() # Add the road closures from the translated Esri dataframe to the Waze service # The supportsApplyEditsWithGlobalIds must be set to True on the Waze service # or the edit operation will fail layer_waze_closures.edit_features(adds=featureset_esri, use_global_ids=True) print('Updated Waze service')

Re: Road Closure Solution producing error in Waze

Jennifer_Parmeley — Mon, 22 Sep 2025 21:32:47 GMT

First - this is awesome and you deserve some kudos and recognition for this work. Thank you!

Second - I apologize for the slow response. Ya know those weeks when everything happens at once? Yeah.

After looking at this with a couple of other folks I reached out to Waze on their partner support forums and then put in a support ticket at their suggestion. They have agreed to accept the 3 ESRI values, in the ArcGIS RC Solution 2.0. I have not tested but should be able to submit 'Construction' 'Event' and 'Hazard' and they should populate to reason (ESRI) or type (Waze).

What I've done to make this work for us.
> I customized the RC Solution hosted feature layer to meet the needs of our city.
> I cleaned up the view I'd messed with and submitted to ESRI and Waze. removing all my "extra" domain values and fields. This made ESRI happy and the view has been accepted to Community Maps.
> I published a second view (of the same Solution layer) to use in our road closure application. This one has all the fields we need/were using and some of the ESRI/Waze fields.

This week will be testing, rebuilding my edit application (again), and implementation. There will be a small about of extra work for the folks that enter our data, but a few extra fields (with domains) should be manageable to make the folks asking for the push to Waze happy. In time we should be able to roll more of the city app towards the ESRI/Waze data, but I'm making small changes slowly in this age of social media warriors.

Re: Road Closure Solution producing error in Waze

CharlesTaylor — Mon, 17 Nov 2025 14:24:37 GMT

Hello Jenifer,

Have you been able to test and confirm the Road Closures 2.0 Values works with Waze yet?

Re: Road Closure Solution producing error in Waze

Joshua-Young — Mon, 17 Nov 2025 16:07:21 GMT

I have not been able to get Waze to accept the feed so far. They said they could not access the secure service even though I provided the username and password they needed to access it. I made the service public back in October and just last week they finally let me know there are still problems. I updated the script I provided above with new subtype values, because apparently the subtype values have changed.

Now I am trying to figure out how to get them the geometry of the lines in a format Waze likes. I originally provided a URL with these parameters at the end:

/query?where=1%3D1&outFields=objectid,street,subtype,description,direction,starttime,endtime,type,reference&outSR=4326&returnZ=false&f=geojson

I got that from the Esri ArcGIS Solution help documentation for the Road Closure solution v1. It outputs the coordinates in WGS1984 decimal degrees and is in GeoJSON format. Waze's software apparently cannot parse that anymore. I have resubmitted the URL to output plain JSON and I am waiting to hear if that corrects the problem. Waze has not made this easy.

Re: Road Closure Solution producing error in Waze

Jennifer_Parmeley — Mon, 17 Nov 2025 16:13:44 GMT

It works, in a limited capacity.
Waze only reads our closures as construction. I can submit 'Construction' 'Event' and 'Hazard' now to Waze without getting errors, but Waze shows all events as Construction. I put in a ticket with their support and the response was basically that they'll report our data how they decide is best. 🤖
We are still using those three categories/domain values because we are using the Solution with Community Map (and Community maps does take the other values).

My solution has been to create a closure area fs for things like sanitary/storm flushing crews - these aren't construction and the road isn't typically closed - but we do want to notify citizens of the workers. These areas are not reported to Waze/ESRI but do get shown on our city dashboard with the Waze/ESRI closures.
https://experience.arcgis.com/experience/56eecd21d3e94750b405278fe22faa00/

We have survey, internal testing started last week, to help staff (and eventually contractors) get all the data we need for Waze/ESRI submitted at one time.

Happy to share more info about what I've done if anyone is interested. It's been one of the longest quick-fixes I've implemented. 🙃

Re: Road Closure Solution producing error in Waze

CharlesTaylor — Mon, 17 Nov 2025 16:27:13 GMT

Thank you Jennifer,

I believe we will use the 2.0 Solution as our request is to simply report closures to Waze and provide a public map for the city's closures which should be easily accomplished if Waze is accepting those values. Tom Tom, and Apple Maps are just a bonus and hopefully Waze will get on board fully at some point!

Re: Road Closure Solution producing error in Waze

Joshua-Young — Mon, 17 Nov 2025 21:41:18 GMT

Waze has finally accepted our feed. The format URL parameter must be JSON for Waze to import the geometry correctly.

/query?where=1%3D1&outFields=objectid,street,subtype,description,direction,starttime,endtime,type,reference&outSR=4326&returnZ=false&f=json

I had to go back and split a few of our road closures because Waze uses slightly different road names than what we had. For example, we have just G Street in our system, but Waze has G Street, G Street West, and G Street South. I left our road name as just G Street, but I split the closure close to where Waze was changing the names.

Also, be careful if you are filling out closure times in ArcGIS Pro. Hosted feature services are in UTC time and ArcGIS Pro is sadly not smart enough to convert UTC to local time and vice versa. ArcGIS Pro shows the time in UTC and it must be updated in UTC. ArcGIS Enterprise and ArcGIS Online are smart enough to convert UTC to and from local time, so enter the times there.

Re: Road Closure Solution producing error in Waze

SamuelDadson — Sun, 19 Apr 2026 05:29:18 GMT

It looks like the core issue is no longer just the domain values, but how Waze is interpreting the schema after Esri’s shift from v1.0 to v2.0 (especially the removal of the subtype field and the change from “type” to “reason”).

One approach that might simplify things — especially if you want to avoid maintaining a full Python ETL — is to handle the translation at the view/export level instead of the source layer:

Keep your main RC solution layer unchanged (to stay aligned with Esri + Community Maps)

Use a dedicated view or export layer for Waze

Reintroduce the required Waze structure there:

Create a constant field for type = ROAD_CLOSED

Map reason → subtype using an Arcade expression or calculated field

Ensure formatting matches Waze expectations exactly (uppercase + underscores)

This keeps your operational workflow intact while isolating the Waze-specific requirements to a single layer.

Also, based on your latest update, it’s interesting that Waze now accepts the values but normalizes everything to “Construction.” That suggests the validation layer may be passing, but their ingestion logic is still constrained on the backend.

Curious if anyone has had success getting Waze to differentiate between Event vs Hazard in production, or if that behavior is consistent across other jurisdictions.

Really appreciate you sharing this — this is one of those integrations that looks simple on paper but gets complicated quickly in practice.