What are realistic global turn delays for fire engines?

3812
15
01-20-2016 07:36 AM
DavidDenham
Occasional Contributor

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?

0 Kudos
15 Replies
ChrisDonohue__GISP
MVP Alum

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

911 GIS

Chris Donohue, GISP

0 Kudos
JoeBorgione
MVP Emeritus

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.

That should just about do it....
DavidDenham
Occasional Contributor

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.

0 Kudos
JoeBorgione
MVP Emeritus

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.

That should just about do it....
DavidDenham
Occasional Contributor

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 firetruck2.JPG

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.   

0 Kudos
ChrisDonohue__GISP
MVP Alum

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

0 Kudos