How is multi-jurisdiction areas being handled in your agency?

Question

Our Parish uses our own dataset for centerlines and address points and we use several different polygons for law enforcement dispatch zones (precincts) and fire response zones (truck order to dispatch) that we pull into our CAD.  In some areas of our Parish, the roadway is one jurisdiction (state police handles traffic incidents), one side of the road is handled by one municipality and the other side of the roadway is handled by a 2nd municipality.  We use to run a geocoder each time the address was queried, but we changed to a table format. The trouble we run into is sometimes the address point will have a different jurisdiction than the centerline and causes an issue. Just wondering what ways are multi-jurisdictional areas handled by your agency.

cterpening · Answer

The use of "block" is a great idea to force the CAD to look at different data. We thought about going back to the geocoder so if there was a different jurisdiction between the centerline and address point, the call-taker or dispatcher could choose. This may take a second longer to get geo selection, but if an accident occurs on the roadway and the centerline is picked, the correct jurisdiction will be selected, and the same for an incident at a house where the address point would be selected.

MichaelFlory · Answer

Hello,

We have similar scenarios with multiple jurisdictions..  Our CAD defaults to look at the address point first, then if no address point it uses the centerline, to ID the jurisdiction.   In our CAD, dispatchers have the ability to type BLK or BLOCK after an address (e.g., 1500 BLOCK)  to get the location to plot on the center line (I think I have it set to approximately 15 ft offset the centerline) to obtain jurisdiction/beat values.   Using even/odd values and BLOCK after the numeric in CAD, tells CAD to look for the data on either side of the centerline.   Without BLOCK, it looks for an address point and CAD returns the values for where the address point is.

Michael