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