Latest Contributions by RobertGarrity

‎03-18-2013

Hello, Although the VRP solver isn't really designed for garbage routing, you may be able to solve your problem by setting the curbApproach of orders to "No U-Turn". This forces the vehicle to continue going in the direction it was going when it arrived at the order. Here's a topic on CurbApproach: http://resources.arcgis.com/en/help/main/10.1/#/U_turn_policies/004700000055000000/ Robert

‎03-13-2013

Thanks for the screenshots, Jenna. It sounds like you have the naming issue figured out. I see you're using hierarchy, which means you shouldn't run out of memory. But I guess that could happen if your computer doesn't have much RAM. How much does your machine have? Here are a couple more things to try: 1. Before loading your stops, open the route layer's Layer Properties dialog box, click the Network Locations tab, check on Exclude Restricted Portions of the Network, then load the stops. Stops will only load on roads that are traversable. Finally, solve. 2. If you still get an error, open the Layer Properties dialog box again, click the Analysis Settings tab, then uncheck the restrictions (Oneway and Turn Restrictions), then re-solve. This should make any unreachable locations reachable. If 2 doesn't work, I think I'll need some data from you, or if you can't send data, maybe you can tell me the counties where you're performing the analysis. This way I could create several random points in the three counties and perhaps figure out where problem areas may be. I'll send you a private message through the forums and include my email address. TIGER data isn't really designed for routing, so it would be best to hold off on that for a bit and try to get the streetmap network to work for you. Thanks, Robert

‎03-12-2013

Hello again, I would ask you to send me some data, but I know this is patient-related, so instead, could you send me three screenshots? 1. For the naming issue, send a screenshot of the Load Locations dialog box as it is when you're loading some stops. I think what's happening is a field from your input data is being mapped to a field on your stops. When the input record has a null value for that field, Network Analyst auto-generates a name that is Location 1, Location 2, ..., Location x. When the input record has a value, that value is added to the Name field of the Stops. I'm guessing the input field contains the 4- and 5-digit numbers you're seeing. 2. A screenshot of the Network analyst window showing the paired stops to verify the stops are loaded properly. To do this, set up a partial problem by loading 10 or 50 pairs of stops only--not all 700+. Expand the Stops category, but don't worry about showing all the stops; a sample is fine. 3. The third screenshot would be of the Layer Properties dialog box--Specifically, the Analysis tab of the route layer. I'm particularly interested in whether you are using hierarchy or not. Although you can just tell me that, it would be good to see what other settings are enabled and disabled. From what you said about solve working for 10 pairs, failing for the 700+ pairs, then failing thereafter, it sounds like this is a memory issue. However, I would expect you to get a memory warning. What happens when you do this: Shut down ArcMap (clear out the memory). Open it back up, and solve 25 pairs. If that works, solve for 50 pairs. If that works, solve for 75 pairs. ... If you run out of memory at 700+ pairs, you'll get failures after that unless the route layer is removed or ArcGIS closed. If memory is the issue, it may be running out of memory if you're solving without hierarchy and one or more stops is on a portion of the network that is disconnected from the rest of the network. (Imagine, for instance, a stop in a gated community and restriction is turned on that blocks the entrance to that community.) In that scenario, the solver will end up searching every edge in the network. Given you're using the North America data, memory would almost certainly be a problem. If hierarchy is disabled, enable it and solve again. You're less likely to run out of memory when using hierarchy since it search far fewer roads than an 'exact' solve. Thanks, Robert

‎03-12-2013

Hmm... Well, here are a couple things to try: 1. Turn on all messages. To do that, on the Network Analyst toolbar, click the Network Analyst drop-down menu and choose Options. On the General tab, turn on All Messages. Re-solve the problem and see if you get any more information than simply 'solve failed'. 2. What happens when you create a new route layer, interactively add two stops, group the stops into a single route, and solve? By 'interactively add', I mean use the Create Network Location tool on the Network Analyst toolbar and click on the map. To group the stops into one route, open the Stops attribute table and calculate the RouteName field. (You could calc the field to "Route1".) Then solve. Does that work?

‎03-11-2013

No problem... Try running the Integrate geoprocessing tool--assuming you have the correct license level. This will create vertices where lines are touching. The issue is that your lines may be touching one another, but in order to connect in the network, the lines need to touch at vertices or endpoints. The attached graphics show what I mean. 1_Without_Vertices.png is what you have currently. The blue dot (hard to see under the selected line) represent an endpoint, the green squares show vertices. There is an endpoint on one line, but there isn't an endpoint or a vertex on the line it touches. The resultant network won't connect there. 2_With_Vertices.png is what the street features look like after running Integrate. When I create a network with Any Vertex connectivity, the route can turn there. By the way, you don't have to run Integrate. It's just a quick way to add vertices where features touch one another. You can add vertices and endpoints through editing or other geoprocessing tools. Robert

‎03-11-2013

Hi Jenna, When you load the stops, are you loading using geometry or network location fields? (This option is at the bottom of the Load Locations dialog box.) If so, what is the Search Tolerance you are using? Also, zoom into an unlocated stop and use the Measure tool on the Tools toolbar to see how far the stop is from the nearest street. What's the distance? If you're using geometry to load locations and the point is farther than the search tolerance, the stop won't locate. The default search tolerance is 5000 meters, so if you're using the default, it's unlikely the stops are not going to be located. But it's a good place to start looking. If you're using network location fields to load, were the network location fields calculated using the same network dataset you're using to create the route layer? Robert

‎03-09-2013

Hello, Your one-way streets seem to be set up fine. Still, there is a video that explains how oneways work, as well as some other network-dataset videos you might find useful. They are available here: http://video.arcgis.com/series/54/network-analyst. I was able to create a network dataset from your data, but there are some connectivity issues which, if ignored, prevent Network Analyst from generating more than the shortest routes. One issue is that the streets connect at vertices, not just endpoints, so when you create the network dataset and are asked about Connectivity, set up "Any Vertext" connectivity. Second, some of the lines aren't connected. Look at the attached graphic, which has an arrow pointing to streets that appear to intersect. However, if you zoom in really close, you'll see they aren't actually connected. You can either edit the streets and use snapping to make sure they connect or use the Integrate tool to auto-snap. Note that the lines need to connect at vertices or endpoints. Robert

‎01-31-2013

Hello Eric, After a couple of days of looking into this when I could, here is what I can report??? As you know, you need a RoadClass field on your lines. Your basic pedestrian paths will have a Road class value of 10. ???Arc-like Connectors???, as I???ll call them, are edges that connect basic paths to other basic paths at intersections or connect basic paths to doors. (Please see the attached graphic. The dashed lines are connectors and the solid black lines are basic paths.) I call them ???arc-like??? because 3D network datasets don???t handle true curves???just straight lines. Any curve needs to be generalized into straight lines. But you can keep the curved look by generalizing them into many short, straight lines. These connectors are often created so the routes solved on the network look more natural and less rectilinear. That aside, the main point here is the arc-like connectors need a RoadClass value of 11. There are four other road class values you can use for directions: 12-Stairs 13-Escalators 14-Elevators 15-Pedestrian ramps Adding a Name field to your features is probably the most useful thing you can add to your network for directions. All point and line source feature classes can have names. Doors can have names to help specify which door a person should use to get into a large room, for instance. Hallways can have names. But named hallways, with visible names, are rare in the real world. Adding an AdminArea field is helpful too. This can store your building name information or names of outdoor areas on line source feature classes, not point sources. Adding FromFloor and ToFloor fields to line feature classes representing floor transitions like stairs, escalators, and elevators will make it so directions say what floor to go to. These are text fields that store the name of the floor, which might be a number or text. You???ll need to supplement these fields with two other Long Integer fields: FromLevel and ToLevel. Make sure they are Long Integer fields, not short ints. Shorts ints should work, but they won???t until the next service pack/release. Assign floor numbers to these fields even if the floors have a non-numeric name. Use ???1??? for the first floor, ???2??? for the second floor, and so on. You can use negative numbers for underground floors. Once you have the extra fields added, you need to configure the network dataset and its directions settings. Add a RoadClass network attribute and configure its evaluators to get values from the RoadClass fields you added to your source features. In the Network Directions Properties dialog box, on the General tab, under Street Name Fields, flip through the different network sources and set Name to the name fields you created on your source features. On the Road Detail tab, set the Road Class Attribute to the RoadClass network attribute you just created. In the Field Mappings section, flip through the sources and set the field mappings below. For floor transitions, make sure you set the Level, FromFloorName, and ToFloorName properties. I hope this is helpful. Robert[ATTACH=CONFIG]21279[/ATTACH]

‎01-29-2013

Eric, Just to let you know, I haven't forgotten about you. I'm still looking into this issue, so this isn't a definitive answer. But what I know so far is that you need a RoadClass network attribute, and it should have values of 10 for lines representing normal hallways and values of 11 for lines representing connectors between hallways or between hallways and doors. So... Add a RoadClass field to your line feature classes. For the lines that represent most hallways, assign a RoadClass value of 10. For connectors, assign a value of 11. Add a network attribute called RoadClass. Its evaluator should reference the RoadClass field from your hallway features. You'll also need to indicate name fields of your source features for directions. Open the Properties for the network dataset. Go to the Directions tab, click Directions. On the General tab of the Network Directions Properties dialog box, choose your network sources in the Street Name Fields section and, under the Name column, choose a name for each source. This name will appear in the directions. So if you want a name for the door, make sure your point feature class has a name field assigned. While you're here, click the Road Detail tab and choose the RoadClass network attribute. You can also set up Administrative Areas (think building names, as in "Enter Building A"). Are you working with multi-story buildings? If you are, we can look into setting Levels (floors) and the from- and to-floors for staircases and elevators. I'm not sure this produces the results you want, but I'll look into it some more and try to provide a definitive answer soon. Robert

‎01-25-2013

Oh, I see. There is a way to answer that question under a certain scenario: you are creating routes for only one school only and the cost of getting the bus back to the house after dropping students off isn't a factor. Otherwise, the solver can't optimally answer that question. Assuming your problem fits the criteria, you can get the result by doing the following: Create a depot at the one school. Create the various routes you need along with their capacities, specialties, and so on. Assign the routes' EndDepotName field value to the name of the depot at the school. Leave the StartDepotName field value as null. This makes the start depot a 'virtual depot', meaning the route starts from an order rather than an actual depot. There can only be one virtual depot per route, so that's why the EndDepotName is specified. Solve to get your routes. Note that driving back to the house of the driver isn't considered in the solution. After you get the solution, you can assign the drivers to their nearest virtual depot (i.e. first order) of a route. The nearest route would tell them which kind of a bus the driver should park at their house. Unfortunately, there isn't a way to assign drivers to vehicles when multiple schools are involved, that is, optimally. There is another option for you if you have multiple schools: you could use a greedy, less-than-optimal approach of iteratively solving for each driver's house. You would do this by adding all your vehicles as routes, setting their start/end depots to one house/depot, solve, lock in the route/vehicle that was chosen, solve for the next house, lock in the vehicle, and so on until all students are picked up. Robert

‎01-25-2013

Hello, Sharyn. Could you achieve what you want by using a more common approach of scaling instead of adding? For example, if the grade is 10%, multiply the travel time by 1.1; if it's -10%, multiply by .95, .94, etc. Essentially, multiply by some number that matches, more or less, the values you are trying to create by adding 2 seconds. If you can do that, I would also suggest creating a new cost attribute in your network dataset that has the original travel time scaled by the effect of slope. Would that work for you? Robert

‎01-25-2013

Hello, Eric. The way to use NA Campus directions is through the Directions GP tool; then set the StyleName parameter to NA Campus. Robert

‎01-25-2013

Hello. The are two main things I think you need to consider: order pairs and assigning routes to depots. To make sure students are delivered to the appropriate school, use order pairs. So for each student, you will have two stops: one at their home and one at their school. Then you link the two together with order pairs. This means you will have a figurative "stack" of stops at the schools--one for each student. (As an aside, school districts often have requirements that limit how long a student can stay on a bus. The reason is that they don't want the student to spend hours of unproductive time on the bus each day, so they may have a limit of say 30 minutes each way. You can set the MaxTransitTime of OrderPairs to try to find a solution that complies with the time limit.) To make sure the routes start and end at the right place--the driver's home--create depots at each driver's house. When you create your routes, assign the Routes' StartDepotName field to the appropriate depot--the one at the driver's home. Do the same for the EndDepotName. You want to make sure the route, which represents a bus, matches the type of bus the driver actually drives. That is, if the driver drives a short bus with a capacity that's less than other buses, make sure the correct depot/home is related to that bus. The same is true for any specialties, like a wheelchair lift or air brakes vs. hydraulic brakes. Hope that helps. Let me know if I can answer any other questions. Robert

‎01-17-2013

You'll want to make sure that the larger vehicles are 'penalized' more than the smaller vehicles. The way you do that is by making them more expensive to run, as should be the case in the real world. In your Routes attribute table, what are the cost field values? Specifically, look at the FixedCost, CostPerUnitTime, and CostPerUnitDistance fields (and, optionally, CostPerUnitOvertime). The one field you'll want to focus on the most is CostPerUnitDistance, since that tends to vary the most across vehicles sizes--larger vehicles tend to consume more fuel per mile than smaller vehicles. So make sure the CostPerUnitDistance is higher for the larger vehicles. You could also add FixedCosts and penalize the usage of vehicles. This would help you fill more buses to capacity since the solver would find it more expensive to send out lots of buses than sending out fewer buses and driving for longer times. Robert

‎01-17-2013

Hello Ernesto, Yes, there is a way to get the VRP solver to do what you want. To take capacity into account, use the PickupQuantities field in your Orders (representing students or bus stops) and the Capacities field in your Routes (representing the buses/driver/path). For both of these fields, you should have two values in one cell: one for passengers without wheelchairs and one for passengers with wheelchairs. The values need to be separated by a space. For example, if the bus has 9 seats and 1 spots for a wheelchair, the values would be entered in one cell as: 9 1 If an order represents a person who rides a wheelchair, the value would be ented as: 0 1 The Capacity Count property on the Analysis Settings tab of the Layer Properties dialog should have a value of 2. This tells the solver you want to model two capacities, which in your case represents passengers without wheelchairs and passengers with wheelchairs. To model driver salaries, use the CostPerUnitTime field in the Routes layer. You'll need to convert their wages into the units that you set for the Time Field Units property on the Analysis Settings tab of the Layer Properties dialog. If you have hours set, you can specify a value that represents wages in $/hour, if you have the property set to 'Minutes', you would need to set the CostPerUnitTime field values in $/Minute. To model gas and maintenance costs, use the CostPerUnitDistance field in the Routes layer. It functions in the same way CostPerUnitTime works. The costs are set per unit distance. You specify the distance units for the analysis in the Distance Field Units property of the Layer Properties dialog. I hope this is helpful. Let me know if I can clarify anything. Robert

Online Status	Offline
Date Last Visited	‎02-15-2024 03:09 AM

My Ideas

Latest Contributions by RobertGarrity

Re: Vehicle Routing Problem - Travel entire street segment?

Re: calculating driving distances

Re: calculating driving distances

Re: calculating driving distances

Re: Help to create accurate database and Routable Network

Re: calculating driving distances

Re: Help to create accurate database and Routable Network

Re: NA Campus directions questions.

Re: NA Campus directions questions.

Re: Network Analyst (NA) - VRS - selecting most effective school buses for routing

Re: how does the added cost of a barrier get calculated when generating service areas

Re: NA Campus directions questions.

Re: Network Analyst (NA) - VRS - selecting most effective school buses for routing

Re: Network Analyst (NA) - VRS - selecting most effective school buses for routing

Re: Network Analyst (NA) - VRS - selecting most effective school buses for routing

Re: Unique turn delay values per junction.

Re: Help pages flip out

Re: Getting signed out when accessing other Esri p...

Re: Does 2.1.2 need be installed on top of 2.1.1?

Re: Network Analyst for wayfinding in indoor envir...