nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

What are realistic global turn delays for fire engines?

DavidDenham

I am new to Network analyst, and I am trying to determine what global turn variables I should use to estimate travel times for fire engines. The delay times that I have seen on GeoNet seem to be somewhat low. For example I would think that when you include the time that a fire engine needs to decelerate and accelerate for a right hand turn that the delay would be greater than 5 to 10 seconds. Am I wrong about that and does anyone have a better idea for what global turn delays should be used?

Find more posts tagged with

Accepted answers

All comments

AndrewDeleteMe

I have the same question, and in fact this is something that appears (is it?) to be a lacking feature in ArcGIS. The city I am working with uses ArcView 3.3 and Arc Markup Language (AML) to create a turn restriction table and append it to a .NWS dataset that is compatible with their CAD product. There has to be a better way to produce these files.

Does this relate to your requirements? If so, I can provide past correspondence between ESRI on the topic and the lack of support for this workflow. I am interested in knowing if anything has changed since then. I would appreciate an ESRI response on this thread clarifying this functionality (Ahem... any ESRI reps want to chime in?).

ChrisDonohue__GISP

I don't know the answer, but let me add a group that has folks that may know:

911 GIS

Chris Donohue, GISP

JoeBorgione

Take a look at my reply here: Good Settings for Global Turn Delay

I guess if you don't like what you find, you can always use what you think is best. Right?!

Oh yeah, creating turn features really suck, no matter how you slice it.

JoeBorgione

How do you use AML with ArcView? I don't even know if ESRI supports either anymore....

AndrewDeleteMe

Yes, that is the problem. It may be a limitation in dispatch system to only accept a certain network dataset formats, but I think it might relate to the inability to add robust turn restrictions in anything other than ArcView 3.3.

I want to move away from this workflow ASAP, so hence my piggybacking off of your prompt.

ChrisDonohue__GISP

Just a guess - maybe the original poster meant Avenue -the scripting language used with ArcVIew (not AML).

Chris Donohue, GISP

DavidDenham

You are right AML was used with workstation and Avenue was only used in ArcView 3.2. Neither language has been supported by ESRI from a number of years now.

AndrewDeleteMe

Just to re-clarify: the turn restriction table is produced using a mix of Arc *Macro Language (AML) and ArcView 3.3 (with some avenue scripts). The AML processes calculate angles and assign impedance values to the turn table for the AV3.3 step. ArcView and Avenue are used for joining the turn table to the network dataset.

I do appreciate how ancient and unsupported these workflows are. I wasn't even born when AML was first designed by ESRI, and I do feel like I should be sporting a Unix beard to work on these scripts. The challenge I am facing is to provide an updated workflow for the customer that is compatible with their current CAD product (TriTech Software Systems). As far as I can tell, Tritech's back-end relies on MapObjects (yes, not ArcObjects, but MapObjects). The City I am working with are looking for a workflow that can support adding a turn table (not a turn feature class) to an existing network dataset (.nws format).

If this is confusing, irrelevant, or just plain impossible using newer technology, then I have to readdress the issue with the customer to identify a newer approach to improve response times. This workflow was designed 20 years ago, so I am leaning toward finding another way to shave time off of their call-response data model. Sorry to hijack your thread, but I am looking into your posts on the global turn delay model for inspiration.

DavidDenham

I guess that I should have said that this is not for dispatch. I received some requests to estimate service areas at 6 and 7 minutes out from the fire stations some time ago. When I tried to calculate the areas using a network that my predecessor had used, the areas generated were too large. When I looked at the network there were no global turn delays and I did not know if the default delays would be large enough to accurately model a fire engine or EMT vehicle. I have looked around and I have found most of the articles that you mentioned in your other post, but no one seems to have an estimate for fire engines traveling on a fairly flat terrain.

JoeBorgione

Without knowing what you predecessor did, I can't make a guess. And who is saying they are too large? And what is that comment based on?

I've created tons of service areas using both time and distance. It's a fairly straight forward process, but fairly data instensive. I don't know how to precisely model acceleration or negative acceleration, and I've not worried too much about doing so. You need good connectivity, one way values and speed limits for your streets feature class. When modeling time, you basically compute how long it takes to traverse a given polyline on at a given speed, and you'll do that as an evaluator.

Turn impedances are not a top priority imho, they are more like icing on the cake. Go ahead and bump them up a few knotches and see what happens. Or, lower your speed limits. Or use barriers as a surrogate to regulate speed/time. One thing for sure is don't expect to get it perfect your first time at it.

DavidDenham

Since I have not had much experience with Network Analyst I might be looking a the results too critically. I look at the distances covered in 6 or 7 minutes for these service areas the results are just not feasible. I am not including traffic data into the calculations and at the widest our city is about 15 mile across, but unless they are using a fire engine like this

the results do not seem to be accurate enough to rely upon. Our centerline data is accurate in regards to speed limits, one way, and connectivity. I do not have a problem playing with the turn delays, but I had hoped with the importance of calculating response time for fire stations that there would some research on the subject available.

Join the Conversation

Signed in members can post, follow updates, and more. New here? Register a free account.

Quick Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.