Latest Contributions by MelindaMorang

The Build Network tool is the final step in network dataset editing or creation.  After you've edited the source features or updated the network dataset properties (which has to be done manually), you have to run the Build Network tool in order for those changes to really take effect in the network. So no, this tool doesn't do everything you want to do, but you will still need this tool as the final step in your procedure. ... View more

Oh, I see.  Yes, you can use python for every step except the network dataset creation and network dataset property editing.   I don't know what you mean by "Can I use Python to set up a GP Tool Model to set the simulation up".  It's also not possible to alter network dataset properties in Model Builder.  You could possibly use ArcObjects to do that, and then you could call your ArcObjects executable code from within a python script. If the only thing that's changing are the street features referenced by the network dataset, you might be able to automate the whole thing.  Before starting your simulations, you could create your network dataset and get all the attributes and other properties defined.  Then, during each run of your simulation, if you edit the street features, you can just run the Build tool on the network dataset so that it incorporates the new edits.  If, on the other hand, you actually need to edit the network's attributes or connectivity properties or something, you will not be able to automate that with python. Have you created a network dataset before?  If not, I think it might be best if you run through the network dataset creation tutorial (ArcGIS Help (10.2, 10.2.1, and 10.2.2) ) first before you continue planning your simulation.  This will give you some idea of what's involved and put some of my suggestions above into context. ... View more

Correct, it's the 'create network dataset' step that is not possible in python. Why do you need to re-create the network dataset every time?  If you just want to solve a route between a different start and end point, you can re-use the network dataset, especially if the points are all within the same geographic area. ... View more

Hello Matthias. For 1), what do you mean by "define a street network in a GDB"?  If you have an existing network dataset, you can easily use it in python for your analysis.  However, it is not possible to create a network dataset (meaning define its source features and set up all its properties) in python. The rest of your steps can definitely be done in python.  Check out the code samples on this page: ArcGIS Help (10.2, 10.2.1, and 10.2.2). There are many code samples like that throughout the Network Analyst tool documentation which should help get you started. ... View more

Hello Francisco. Whenever you load locations into a Network Analysis layer, you can use the field mapping control to transfer attributes from the input feature class to the NA layer's Stops/Facilities/Origins/Destinations/etc.  The input class in the NA layer doesn't automatically inherit all the fields from the input data.  If you have an ID field, you could map that to the Name property in the NA layer.  Or, before loading your input data, you could use the Add Field to Analysis Layer tool to add a custom field to the NA sublayer, and then you could map the field in your input to the custom field.  Suppose your feature class of firms has a field called firmID and you want your Facilities sublayer in your Closest Facility layer to also have this field.  You would have to add the field to the Facilities sublayer with the Add Field to Analysis Layer tool and then map the fields during the Load Locations process. See this page for more details: ArcGIS Help (10.2, 10.2.1, and 10.2.2) For your analysis, is each firm matched to a specific customer or set of customers, or are you actually trying to find the "closest facility" to each one?  If you already know which pairs go together, and these pairs aren't necessarily the closest, you should use the Route tool rather than Closest Facility.  There's a way you can use field mapping with the RouteName field to specify which pairs of points should be on the same route which I can describe in further detail if this is what you're trying to do. As far as splitting the resulting routes by state to find out the distance traveled in each state, check out this video of a presentation from the Esri User Conference which contains a demo of exactly this problem: Network Analyst: Performing Network Analysis | Esri Video It starts around 13:00.  The material prior to that in the video explains a bit about field mapping. ... View more

This sounds like an issue you should report to Tech Support.  They can log a bug for the crash and help you figure out a workaround.  http://support.esri.com/ ... View more

Does one of the cost attributes on your network dataset have a space or other special character in the name?  I've seen that "specified column does not exist" message in that circumstance.  If your network does have a cost attribute like that, rename it to something with only letters, digits, and underscores, rebuild the network, and try your solve again. ... View more

Hi everyone. When using detailed polygons in Service Area, holes are normal and expected.  Detailed polygons provide the most accurate representation of the area that can be reached within your time or distance limit.  It is quite possible that there might be pockets of unreachable areas completely surrounded by reachable areas.  For instance, it could take quite a bit of time for your fire truck to wind its way through a bunch of curvy subdivision roads to the end of a cul-de-sac, so the cul-de-sac might not be reachable even if the surrounding roads are, leaving a hole in the middle.  You might also have a stretch of road with a restriction on it, and Service Area polygons will not be drawn around it if the road is restricted in the analysis.  Finally, there might simply be a large area with no roads, such as a river or lake or forest. That said, the holes you're getting might be a symptom of a problem with your network dataset (and the screenshots make me think this is indeed the case).  In addition to the topology issues mentioned above, there are a few reasons why some - Your road has a one-way problem where both directions of travel are restricted (a 0-way road). - The impedance is calculated incorrectly for the road, giving it an extremely high value that makes it effectively unreachable. - Your road has a restriction placed on it incorrectly.  For instance, there might be a height restriction with an unreasonable height limit. - The roads intersecting this one connect to it at vertices, but you're using an End Point connectivity model, so the roads don't actually connect. Some debugging tips: - Run the service area again with all the same settings, but check on line generation.  Are the Service Area lines covering the roads where the polygon holes are?  If not, then that looks like a symptom of a network connectivity problem. - Create a Route analysis layer and drop two points on either side of that one troublesome road segment.  Can you calculate a Route and force it to cross that road segment, or does it loop around the block instead in order to get to the other side? - Use the Network Identify tool (on the Network Analyst toolbar) to click on the problem road.  A pop-up window will appear, and it will show you a list of all the junctions and edges that are connected to that road.  You can click on the items in this list, and it will highlight them on the map.  If the road isn't connected to the surrounding roads the way you expected, then you have a network connectivity problem that needs to be solved. ... View more

It think you can accomplish this in your model as follows: - Make Route Layer - configure it to find the best order (rather than using input order) but to preserve both the first and last stops.  That way the first and last one will remain first and last, but the middle ones will reorder for the optimized route. See ArcGIS Help (10.2, 10.2.1, and 10.2.2) - Add Locations 1 - your user's first selected stop (the starting point) - Add Locations 2 - all the intermediate stops that you already know - Add Locations 3 - your user's second selected stop (the end stop) - Solve ... View more

Sorry, I was unclear.  What I meant is, have you tried adding the network dataset to ArcMap just to play around with it to make sure it works at all?  Just try running a few manual tests in ArcMap.  If you can't get it to work manually within ArcMap, then you certainly won't be able to get it to work in your script. Regardless, I think I see where the problem is in your MakeVehicleRoutingProblem statement: arcpy.MakeVehicleRoutingProblemLayer_na(inNetworkDataset, outNALayerName, impedanceAttribute, distanceAttribute, timeUnits, distanceUnits, "USE_HIERARCHY", "TRUE_LINES_WITH_MEASURES") You have to have the input parameters in the correct order and placement.  Everything is fine up until "USE_HIERARCHY".  In that place, it's expecting the default_date parameter, and it's confused because you're telling it to use a value of "USE_HIERARCHY" for default_date, which it doesn't understand.  If you don't want to set a default_date or any of the other parameters between there and hierarchy, you can just explicitly identify the parameter you're using like hierarchy="USE_HIERARCHY": arcpy.MakeVehicleRoutingProblemLayer_na(inNetworkDataset, outNALayerName, impedanceAttribute, distanceAttribute, timeUnits, distanceUnits, hierarchy="USE_HIERARCHY", output_path_shape="TRUE_LINES_WITH_MEASURES") A complete list of Vehicle Routing Problem parameters, and their correct ordering, is here: ArcGIS Help (10.2, 10.2.1, and 10.2.2) ... View more

The problem probably occurred when you tried to persist the in-memory OD layer to disk by saving the mxd.  It probably ran out of memory.  It's a limitation of ArcMap's 32-bit architecture.  I doubt if you can recover your results from a NAX file.  My recommendation for future endeavors is to export the Lines sublayer to a feature class so you will have the results on disk to work with in the future.  That will probably be easier on the system than saving the mxd with the layer inside. If solving a huge NA analysis becomes a problem, you can run it using the 64-bit background geoprocessing extension, and you can avoid running out of memory that way, but that won't help for saving mxds with gigantic layers in them. ... View more

Hi.  Can you post the exact error message you're getting?  Was that class Queue.empty thing all you got? Also, is this actually a path to a network dataset? "F:\\Workspace\\Sandy\\GM_costAnalysis\\streets" Can you add it to ArcMap and create a Route or Service Area with it there?  If not, then your script certainly won't work. As far as looping goes, that shouldn't be too difficult.  If you want to use all the same settings and stuff, you can just create a list of your input orders and depots and loop through it.  Each time you run Add Locations, take the correct ones from your list.  Make sure you set Add Locations to "CLEAR" instead of "APPEND" so that the existing orders and routes are cleared out and replaced with the new ones, rather than the new ones being added to the existing ones.  Then, make sure you're doing whatever you need to do with your solved output before the next iteration of the loop, because it will be overwritten. ... View more

In order to calculate an OD Cost Matrix (or any of the other Network Analyst analyses), you have to add your point locations to the NA layer.  For instance, you have to take your post codes and add them as Origins.  What this procedure does is it examines the original geographic location of the post codes and finds the location on the network where that location falls.  So, if a point falls a few meters off the side of the road, it assumes that the starting point of any journey originating at that point would just be the closest point on the road network to that point.  It's like the point where the driveway touches the street, even if you would have to drive 100  meters down the driveway to actually reach the front door. The Search Tolerance simply determines how far from a road a point is allowed to be before it is considered to be too far from the network to be considered in the analysis.  For instance, if you have a point that accidentally got placed way out in the middle of the ocean, a search tolerance of 5000 meters will generally ensure that that point is excluded from the calculation (and you'll see an error on that point saying it couldn't be located on the network). The reason you would want to use a very small search tolerance is if you have some compelling reason to insist that all points must be very close to the network.  If, for your analysis, you don't care, as long as they're not accidentally placed way out in the middle of the ocean, then the default search tolerance, or any reasonable search tolerance you determine, should be fine. You got the same results for each OD pair when loading them all together with a large search tolerance and when you loaded them in three tiers of search tolerance.  This is completely expected, and correct.  The travel time between two points on the network should be exactly the same if those two points snapped to the same point on the network each time you loaded them.  Since search tolerance is simply a limit after which the point will be ignored, it should always locate at the same point if it locates at all, unless you adjust the location settings in some other way. Now, if you're trying to calculate shops within 800 meters of each postcode, and your search tolerance is 5000 meters, it is conceivable that you might have a few problems.  The 800 meter limit you can set on your OD Cost Matrix is 800 meters of network distance.  The setback from the street isn't factored in.  So, if you have a post code that is set back 4000 meters from the street, and a shop that is set back 4000 meters from the street, but they snap to points on the road that are only 500 meters from one another, then they will show up as below your 800 meter threshold, even though if you consider the distance you have to walk along the driveways to get to the actual locations set back from the street, it would be 8500 meters. If you wanted to get really fancy, you could pre-calculate the distance to the network and add that in as an extra, individual amount of impedance for each Origin and Destination (you can use the Attr_ field). That said, what are your post codes, anyway?  Are they just centroids of some polygon postal code region?  If so, then the actual location of the centroid isn't very meaningful.  I mean, a postal code doesn't have a driveway, right?  So the road setback may not be worth considering to the level of exactness I just described.  It's up to you to figure out what works best for your data, but hopefully the above description will help your boss understand the nuances of search tolerance a bit better.  There's no need to do the analysis in three tiers if the only thing you would be changing is the search tolerance. ... View more