topic Re: What are realistic global turn delays for fire engines? in ArcGIS Network Analyst Questions

What are realistic global turn delays for fire engines?

DavidDenham — Wed, 20 Jan 2016 15:36:25 GMT

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?

Re: What are realistic global turn delays for fire engines?

AndrewTangeman1 — Tue, 02 Feb 2016 19:41:39 GMT

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?).

Re: What are realistic global turn delays for fire engines?

ChrisDonohue__GISP — Tue, 02 Feb 2016 19:55:09 GMT

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

911 GIS

Chris Donohue, GISP

Re: What are realistic global turn delays for fire engines?

JoeBorgione — Tue, 02 Feb 2016 21:38:43 GMT

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.

Re: What are realistic global turn delays for fire engines?

JoeBorgione — Tue, 02 Feb 2016 21:41:45 GMT

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

Re: What are realistic global turn delays for fire engines?

AndrewTangeman1 — Tue, 02 Feb 2016 21:48:28 GMT

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.

Re: What are realistic global turn delays for fire engines?

ChrisDonohue__GISP — Tue, 02 Feb 2016 22:44:46 GMT

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

Chris Donohue, GISP

Re: What are realistic global turn delays for fire engines?

DavidDenham — Wed, 03 Feb 2016 03:03:44 GMT

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.

Re: What are realistic global turn delays for fire engines?

AndrewTangeman1 — Wed, 03 Feb 2016 04:02:12 GMT

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.

Re: What are realistic global turn delays for fire engines?

JoeBorgione — Wed, 03 Feb 2016 14:18:12 GMT

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.

Easy now, some of us cut our teeth with aml, arcplot command line, and unix....

...back-end relies on MapObjects (yes, not ArcObjects, but MapObjects).... ....This workflow was designed 20 years ago...

Leeches were once used for certain medical treatments. And I thought I was old an in the way....

As long as we are talking in the past tense, here is a thread I participated in back in '07:

Creating turntable

Re: What are realistic global turn delays for fire engines?

AndrewTangeman1 — Wed, 03 Feb 2016 16:42:10 GMT

Thank you so much! That thread perfectly summarizes the workflow and why it was designed that way. You are indeed wise! I was feeling out of my league with these processes, but I am beginning to understand how they work.

I hope to poke around the dev summit and find some info on newer 911 response models. I feel a lot has probably changed to improve these types of workflows.

Re: What are realistic global turn delays for fire engines?

DavidDenham — Wed, 03 Feb 2016 22:12:55 GMT

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.

Re: What are realistic global turn delays for fire engines?

JoeBorgione — Wed, 03 Feb 2016 23:44:02 GMT

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.

Re: What are realistic global turn delays for fire engines?

KimOllivier — Thu, 04 Feb 2016 22:48:34 GMT

I too have kept using AML and Avenue for network and allocation tasks way past their use-by date. It was because there just weren't the tools to customise the basic network at 9.x to make my applications work.

But now I have finally moved entirely to ArcGIS 10.x and Python. It works better and there are better analysis tools that do a very good job of allocation that makes it simpler than my own hack. I needed to allocate for hundreds of centres that were not fixed. In the past I ran an interative process that required building a new network for each cycle.

Converting from turntables and other turn restrictions from a Garmin database were very difficult, but in the end I was able to transfer all the turn restrictions using arcpy's new geometry functions. I was able to generate turn features by drawing a line from the midpoints of the connecting segments. So if you have a set of restrictions it is now as possible as it was with AML/Arcedit and Avenue/ArcView3 by using python and arcpy.

Re: What are realistic global turn delays for fire engines?

DavidDenham — Fri, 05 Feb 2016 14:42:37 GMT

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.

Re: What are realistic global turn delays for fire engines?

ChrisDonohue__GISP — Fri, 05 Feb 2016 15:51:21 GMT

Just at thought that may stimulate some ideas:

Is there a standard methodology for determining response times that is in use for Response? I know our City's Fire folks have mentioned trying to achieve a certain level of response based on time, so I'm curious - is there a standard? I suspect it won't one be one down to GIS-level details, but maybe one that lays out the expectations? If there is, would that provide guidance that could then be used to help in then deriving how to handle turns?

Chris Donohue, GISP