Latest Contributions by RobertGarrity

Josh, You can try the Network Analyst Traversal Result add-in that Patrick Stevens posted on the Resource Center. It outputs features that are traversed during an network analysis. From there, you can use the junctions feature class, which is ordered for you. (Note that this feature class includes points that represent stops and added-cost/scaled-cost barriers in the analysis.) Good luck, Robert ... View more

Hello. I saw in your other post that you said the following: When I did the build of my network dataset, it did not put a "ND junction" point at all these points (and I can't see any pattern in where it opted to put one vs. not put one). Any of my "POC" points that are not coincident with the ND junction points produces a standalone error. What this tells me is that the points you are creating and that are giving you the stand-alone error aren't truly coincident with the endpoint/vertex of a line. Try zooming in really close, I don't think the problem junctions you created will be coincident with the ND_junctions (AKA "system junctions"). In fact, Network Analyst shouldn't create a system junction on top of user-defined junction. Try these steps as a test: 1. Start an edit session to edit the junctions you created. 2. Add the snapping toolbar and turn on all snapping except for edge snapping. 3. select one of your problem points with the Edit Tool. 4. Drag it so that it snaps to the system junction that appears to be on top of it. 5. Stop editing and save your edits. 6. Build the network. 7. Create a route and see if you get the expected results. Please let me know if that was the issue or not. Thanks, Robert ... View more

Hello, Bob. It looks like this is a problem that has to do with the interplay of network hierarchy and restrictions. There's a lot to it, but I'll try to explain. When hierarchy is used in a solve, the solver looks for ways to step up the hierarchy levels and, as it does so, filters out lower-levels of the hierarchy from the search. This hierarchical filtering process is optional, and is offered to speed up the solve time; however, a drawback is that it makes the network more sparse, and thus makes it more likely for the network to become disconnected, which in turn would make it impossible for Network Analyst to find a solution. (Another drawback is that a solution may be less than optimal.) There's a help topic that explains the basics of hierarchy: About network analysis hierarchy. See the graphic at the bottom of the topic for a quick explanation of broken hierarchies. "Hierarchy transitions" are the points in the network where edges with lower level hierarchy values connect to edges with higher level hierarchy values. As the route is being solved, a limited number of hierarchy transitions are found before Network Analyst stops searching for higher levels or for the connecting backwards search from the second stop. (If it connects with the backwards search, a solution is found.) If the transitions found exceed a maximum specified number, and a solution isn't found or the highest level of the hierarchy isn't found, the solve fails. By tossing restrictions (and barriers) into the mix, the network is more likely to become disconnected. Also, the edges that are searched and the transitions that are found are likely to change when restrictions are present. What's happening in your case is the non-exhaustive hierarchical search is funneled to different areas of the network due to different height restrictions. For example, the route you solve for vehicles with a height of 177 inches hit a restriction earlier on in the search than the vehicles with a height of 176. Therefore, the searches for the two different routes continue in different areas of the network. As you can see in the attached graphic, the route for the 176 inch vehicle doesn't quite find the backwards traversal. (The points in the graphics represent the junctions that were reached in the search. The two red ovals highlight where the bidirectional search almost connected.) A big factor in failing to find a solution here is that you are restricting tollways, and tollways make up most, if not all, of your 1st level hierarchy. So if the solver can't get up to the highest level, it will only search out on the second-highest level until the default limit of hierarchy transitions are found. If it could get on the highest level, it wouldn't limit itself by transitions, instead it could potentially search the entire level. As long as both searches in the bi-directional search can reach the highest level of the hierarchy, and the hierarchy isn't disconnected, you've got a route. So that's the general problem, below are some solutions. Solution 1: Turn off the hierarchy. Restrictions can still disconnect two areas of a network even with hierarchy off, but they are much less likely to do so. In this problem, a solution is found when hierarchy is off. Solves will take a bit longer with this solution, but you won't have as many failures. Solution 2: Adjust the hierarchy of your network. This is to compensate for restricting tollways (i.e., the highest hierarchy level). I'd suggest redefining the hierarchy to four levels and group Func_Class values of 1 and 2 into the highest level (1). Solves will take a bit longer with this solution as well, but you won't have as many failures either. Solution 3: Increase the maximum number of transitions searched. This is a very advanced solution because it requires editing your system's registry. I'm just mentioning it, but not recommending it. It's done by... 1. Adding a DWORD value to the following key: HKEY_CURRENT_USER > Software > ESRI > Desktop10.0 > NetworkAnalyst > ODCostMatrix > MultiAStarAlgo. 2. Naming the DWORD value "NumTransitions". 3. Entering a numeric value for NumTransitions. I tried bumping the value up to 40 and the route solved successfully, you could probably get away with using a smaller number. (Deleting the DWORD value entirely returns the number of hierarchy transitions that are searched to the default.) Again, solves will take a bit longer if you use this method. I hope this is helpful to you. Let me know if I can try to clarify anything. Best, Robert ... View more

Hello, IsabelM. Let's assume you have two attributes on your source feature class that represents rural roads: Meters and RoadClass. 1. Create a network cost attribute. 2. Set the evaluators for the to-from and from-to directions of the roads source to be field evaluators and set their pre-logic section to the following: result = 0 Select Case [RoadClass] Case 1, 2, 3 result = [Meters] * 60/5500 Case 4, 5, 6 result = [Meters] * 60/3500 End Select 3. Set the "Value =" text box to result. 4. Build the network. 5. Optionally, verify the values for roads are what you expect by using the Network Identify tool on the Network Analyst toolbar. ... View more

I haven't received anything yet. Did you send it to rgarrity@esri.com? Thanks, Robert ... View more

Thanks for posting the info about the attributes, Robert. Unfortunately, I'm not sure what is causing this issue given what I know so far. Would you mind clipping out the source features around the area of your route and sending them to me to see if I can fix the problem? My email address is my user name followed by @esri.com. ... View more

My hunch is that there is an issue with the evaluators for one or both of the network attributes that are required to set up a height restriction. (One descriptor attribute is required to get the max height value from the source features, and a restriction attribute is required to compare a parameter value indicating the vehicle height with the max height value.) Could you post what type of evaluators you're using and how the values are calculated so that I can try to spot any problems? I'm guessing you would have something like the following: 1. Max Height Descriptor Attribute: Attribute Name--MaxHeight Attribute Type--Descriptor Evaluator Type--Field Evaluator Logic--[MaxHeight] (That is, the network attribute value is pulled from the MaxHeight field of your source feature class.) 2. Height Restriction Attribute: Attribute Name--HeightRestriction Parameter Name--VehicleHeight Attribute Type--Restriction Evaluator Type--Function Evaluator Logic--MaxHeight < VehicleHeight (That is, the edge is restricted if the vehicle height parameter is greater than the maximum height descriptor attribute value. Note that one possible cause for the unexpected routes is that your comparison operator might be an equals sign rather than a less-than sign.) Regards, Robert ... View more

Validating your GP model might fix your issue. (In the ModelBuilder window click the icon with the check mark.) Note that once you validate your model, you may have to set some parameters again as they will be reset in the process. If that doesn't work, would you be willing to post or email your data, including the network analysis layer, GP model, and network dataset? (rgarrity#esri.com) I could take a look and see what else might be the issue. Thanks, Robert ... View more

Hi Jake, Have you tried the Integrate GP tool (Data Management)? If you decide to use it, make sure you back up your data first, since this tool modifies the input data. Also, make the tolerance as small as possible so that the tool doesn't get overzealous and adjust lines that are far apart. Note: Although you can add multiple feature classes as input, you only need to add just one--your line feature class. I hope this works for you. Robert ... View more

Hi Lisa, Regardless of whether there is a bug, there is a simple workaround, so you should be able to do what you want. As I understand your data, you have one-way streets, which are always one way in the digitized direction of the source street features. (The important part here is that they are never one-way against the digitized direction.) In this case, you should try to... 1. Create a field evaluator for the from-to direction of your source feature class. 2. Set Value = false in the Field evaluator dialog box. 3. Create a field evaluator for the to-from direction of your source feature class. 4. In the Field evaluator dialog box's pre logic section, enter something like: restricted = false if [your oneway field name] = 1 then restricted = true end if 5. Set the value section to restricted. The evaluator for the from-to direction basically says that this traversal is never prohibited in that direction (since your data is designed this way). The evaluator for the to-from direction says that if the value of your one-way field is 1, the street is prohibited in the to-from direction, which implicitly means the street is one-way in the from-to direction. Best, Robert ... View more

First question: which program to use? Should I perform the network analysis as 2D in ArcMap and then somehow visualize it into 3D? Technically, 3D network analysis is performed through geoprocessing, so you don't need ArcMap or ArcScene for the analysis part. But you'll probably want to use ArcScene for visualizing the results. Also, if you have input stops that you want to add interactively, you can do that much more accurately in ArcScene than ArcMap. So the simple answer is, use ArcScene. ...ArcScene doesn't allow me to upload my network dataset... When you try to add a network dataset to ArcScene, you'll get an error. This is expected, because as you noted, ArcScene can't display network datasets. What you can do is add your source features classes instead. The geoprocessing model you create will reference a network dataset, so ArcScene doesn't have to reference it. I just want to find the route between a couple of points but this seems infeasible with the add locations tool... Do you want to add the stops interactively or load them from a points feature class? If you want to add them interactively, make sure that your input locations on the Add Locations tool is set as a parameter in your model and its data type is feature set. The Help topic that you reference goes along with data from the tutorial media. Take a look at the Input Stops parameter on the Add Locations tool of the provided model for an example; specifically... Right-click Input Stops in ModelBuilder and choose Properties. In the Input stops Properties dialog box, click the Data Type tab. Note that Select Data Type is set to Feature Set. This allows you to interactively click in ArcScene to add stops to the analysis. One other point to be aware of is that you should be able to swap out the network dataset in the tutorial model with your own 3D network and it should just work, as long as you add stops by clicking on your own source features in ArcScene so that they can be located on your network. Good luck! Robert ... View more

Thanks... Once the Add Locations are added twice for the incident and facilities, do I need two Solve tools? No problem, Mark. You would just need one Solve tool for the analysis. To illustrate, here is what a basic CF model would look like this: Make Closest Facility Layer --> Add Locations --> Add Locations --> Solve. All network analysis layers (e.g., a closest facility analysis layer) are made up of several sublayers, which in turn contain the input and output features for the overall network analysis layer. These sublayers are created automatically whenever you create a network analysis layer so that you don't have to do that work of creating all the input/output feature classes yourself. All you need to do is load data into the sublayers (using Add Locations) and possibly set their properties. Closest facility requires the Facilities and Incidents sublayers to be populated with features before solving--they are required input data. If either of these two sublayers aren't populated, the closest facility solver won't have enough information to generate a solution. You use Add Locations once to add input data to Facilities and run it again to add input data into Incidents. You use the Solve tool once and only once to solve the entire closest facility analysis layer. Also, I would like to retain the fields from the input facilities. I noticed it generates a unique identifier allowing me to join/combine, but is their a way to carry over all facility input fields to avoid the extra steps? Check out the Add Field to Analysis Layer tool. This adds a field to one of the sublayers of an overall analysis layer. For example, use this tool immediately after Make Closest Facility Layer, specifying the sublayer you want to add the field to (for instance, Facilities). You can even chain a series of Add Field to Analysis Layer tools if you need to add several fields. Once you've set up all the fields you want to add, link up your Add Locations tools. You can map fields using Add Locations so that the data from your original feature classes are carried over to your sublayers. (If you use the same field names and data types the fields you add are mapped automatically.) ... View more

Hi, Mark. After adding the Make CF tool to your model, you'll need to use the Add Locations tool to load facilities and then use Add Locations again to load incidents. After the inputs are loaded, you can link up the Solve tool. Exercise 6 in the Network Analyst tutorial shows how Add Locations is used with the Make Route Layer tool, so you might want to reference that. Just keep in mind that the only real difference between the model in exercise 6 and a simple CF model is that routes only require stops as input so Add Locations is used once, while CF requires facilities and incidents as inputs so Add Locations is used twice. One other note--if you need to load barriers for any analysis layer, use Add Locations for them as well. ... View more

If I understand your objective correctly, you want to find the driving distance from one specific origin to one specific destination, not from all origins to all destinations. This is important because, at first glance, you might think the OD cost matrix solver would work best, but actually it's probably best to do the following using a route layer instead: 1. On your dataset, create a new field named RouteName and calculate its value so that it is the same value as your current ID field. 2. Add your origins to ArcMap as a layer. (Tip: File > Add Data > Add XY Data.) Only specify the origin X and Y fields. 3. Rename the output layer that appears in the table of contents to something like Origins. 4. Add your destinations to ArcMap as a layer. Only specify the destination X and Y fields. 5. Rename the output layer to Destinations. 6. Make a Route layer using the Network Analyst toolbar (or a GP tool). 7. Load the Origins layer into the Stops class. (Tip: Right-click Stops in the Network Analyst window and choose Load Locations.) Make sure the RouteName field is mapped to the RouteName field you created. 8. Load the Destinations layer into the Stops class using the same method. 9. Solve By specifying the route name when loading, the stops are grouped together and routes are calculated only for the stops that are in the same group, which in your case is limited to a single origin and destination pair. You can open, and optionally export, the Routes class, which contains the calculated shortest-path driving distances. The Name field values will match the values of your original IDs. ... View more

What you want to do is possible, and as I understand your objective, the way to do it is by adding turn features. A turn feature represents a movement from one edge to another (or back onto the same edge where it started for a U-turn). Like edges and junctions, a turn can also have a unique time penalty. The steps below outline how you can incorporate unique turn penalties into your network. 1. Create a turn feature class, perhaps called "TurnPenalties" 2. Add an field to the feature class; call it something like "Penalty". 3. Digitize turn features and record their unique penalties in the Penalty field. (It may be simplest to use the same units as your network cost attribute.) 4. Once you've saved the turns you've digitized, and you've stopped editing... ...Open the Network Dataset Properties dialog box. ...Open the Evaluators dialog box for the cost attribute you're solving your routes on. ...Make the "TurnPenalties" source use a field evaluator. ...Set the "Value" column to "Penalty" (the name of the field). This causes the network dataset to read the turn penalty values from the Penalty field you created. ...Build the network and perform your analysis. If you square the number of junctions in your network, you get the number of potential turns. Even for a small network, that's a lot of potential turns. To minimize the number or turns you have to digitize, try to use the global turn delay evaluator where you can. So keep in mind that the penalty of a turn feature OVERRIDEs the penalty of a global turn at an intersection. So if some of your turns can be given generic values, use the global turn delay evaluator for them and then digitize turn features only where their turn penalties need to be unique. One other point to be aware of is that the Global Turn Delay Evaluator allows you to assign values by turn direction and hierarchy level. If you can base your turn penalties on hierarchy, you might not have to digitize any turns. Also, there are many more turning possibilities than shown by default in the Global Turn Delay Evaluator dialog box. To see more, click "Load From File" and browse to: C:\Program Files (x86)\ArcGIS\Desktop10.0\NetworkAnalyst\NetworkConfiguration\AllNetworkGlobalTurnDelaySettings.xml Good luck! Robert ... View more