Latest Contributions by MelindaMorang

Okay.  Python would definitely help you out here.  But, what I was asking is what you want to do with the data after you've found the distances between origin and destination.  Do you just want to read it from a table or are you using as input for something else?  Putting it into a database?  The end goal can help us figure out how best to export the data from ArcMap in a format that works for the end goal. ... View more

Do you know any python?  If so, you can solve the OD Cost Matrix and then use a search cursor and a for loop to read the values of the table and write them out to a csv file using python's csv module.  But, the file may still be too large to open in Excel (which is a limitation of Excel and not ArcGIS).  What do you ultimately want to do with the OD Matrix output? ... View more

As bsriramak said, this is probably not a problem with Turns.  Turns are just used for applying time penalties or restrictions on specific turns.  By default, the network will allow you to make turns between any two connected roads at an intersection. So, the more likely problem is that your network isn't well connected.  Here's how you can investigate: - Zoom in to an intersection that's giving you problems. - Use the Network Identify tool (on the Network Analyst toolbar) and click on one of the roads that goes into that intersection.  Does it have an endpoint at the intersection?  Do the other roads that meet at that intersection show up in the adjacent edges list?  You can click the adjacent edge numbers in the Network Identify window to highlight them on the map. - If all the roads that should be connected  to your road aren't actually connected, then you need to fix your network. To fix a network that isn't well connected: - First, open your network dataset properties and look at the connectivity tab.  If your street feature class has vertices at the intersections but not end points, you might be able to fix your problems by switching to Any Vertex connectivity instead of endpoint.  Read http://resources.arcgis.com/en/help/main/10.2/index.html#/Modifying_connectivity/00470000001v000000/ for some tips. - If your street features don't have vertices there either, you might need to run the Integrate tool.  This tool will create vertices at the points where features touch each other.  You have to be careful, though, because it will create vertices in places where they might not belong, such as highway overpasses. ... View more

Yep, those are pretty crazy looking.  Can you share your data (network dataset and mxd with NALayer)?  I would be happy to take a look at it for you and see if I can figure out what's happening. ... View more

Are you using any restrictions in your analysis?  Perhaps the roads your routes refuse to travel on are restricted. Does your network have turns in it?  Perhaps particular turns through an intersection are restricted or have large delays imposed on them, which discourages travel there. Maybe your network isn't well connected.  Pick one of the intersections in question and use the Network Identify tool (from the Network Analyst toolbar) to click on the streets leading into that intersection.  In the box that pops up, you'll see the edges and junctions that are connected to the selected road.  If you click on them in the Network Identify window, they will highlight on the map, so you can make sure that all the roads that should be connected actually are. ... View more

Hi Stanley.  When you run a network analysis, there are two things that have to happen with your network dataset.  First, the stops or facilities or origins or destinations you are using for your analysis have to be "located" on the network, meaning that their positions snap to the closest network edge.  Second, after their positions on the network are determined, the solver can solve a route between them or find the travel time or whatever.  The restrictions you've set up prevent or discourage the routes from using the restricted roads.  However, what's happening in your case is that the points are actually locating on a piece of the network that's restricted.  So, the closest network edge to your facility is a restricted edge.  The only way a route can be generated to that facility is to travel on a restricted edge. Here's how to avoid this problem: Open up your analysis layer properties and go to the Network Locations tab.  There's a checkbox at the bottom that says "Exclude restricted portions of the network".  Check that on and then reload your facilities/incidents/etc.  That will ensure that your points locate on the closest non-restricted network edge. ... View more

I think you just have a typo. tableName = ["CFRoutes"] should be: tableName = subLayerNames["CFRoutes"] ... View more

Where in the code are you getting this error message?  Can you post your new code? ... View more

Hi Claudia.  It is true that ArcGIS Desktop is a 32-bit application.  However, there are a few things you can do to speed up a very large calculation: 1)  Install the 64-bit Background Geoprocessing product.  This way, when you run ArcToolbox tools in Desktop, if you have background geoprocessing enabled (in Geoprocessing->Options), the tool will run in 64-bit mode, which speeds things up quite a bit.  Note that you have to be running the ArcToolbox version of Solve instead of clicking the little Solve button on the Network Analyst toolbar.  You can also run python script tools using 64-bit background GP by simply calling the 64-bit version of python.  The documentation explains it in more detail: http://resources.arcgis.com/en/help/main/10.2/index.html#//002100000040000000 2)  You can use python�??s multiprocessing module to run several analyses in parallel.  This is extremely helpful if you have a problem that can be broken up into multiple solves.  Setting up the multiprocessing is simple in principle, but it doesn�??t always play well with ArcGIS, so it�??s a bit tricky. Also, are you using a network dataset you built yourself?  If the network dataset has poor connectivity (lots of roads that are disconnected from one another unintentionally), solves will take longer.  If an origin or destination snaps to a disconnected network segment, the solver might have to search the entire network trying to find a path before it gives up and says there is no solution. I hope this helps a little.  Good luck. ... View more

Try creating a fresh geodatabase and feature dataset and starting over with a fresh network dataset.  I think sometimes the "table already exists" message occurs when something didn't get deleted all the way from the geodatabase, and the best solution is to just start over. ... View more

"Walking" assumes you're walking.  In the background, I believe it's simply restricting streets based on an attribute in the street feature class that indicates that pedestrians are forbidden.  I agree that the naming convention is a bit confusing.  For a pedestrian analysis, "Walking" should be checked. To eliminate one-ways, just turn the one-way restriction off (assuming there is one).  If one-way is unchecked, one-way values will be ignored. If you solve your analysis using a distance measure (such as Miles or Meters), the solution will be optimized based on network distance rather than travel time.  The travel time impedance attributes are generally designed for cars, and they use the traffic data and speed limits.  However, the distance-based impedance attributes are ignoring all that and only using distance in the optimization, so it can be used for a pedestrian analysis. The main limitation you will run into with your network will be pedestrian paths or cut-throughs that aren't included.  Pedestrians can walk on paths, across parks, through buildings, etc.  However, the basic street network with a distance impedance attribute will give you something reasonable to work with.  You could certainly make your own network dataset designed for pedestrian analysis if you have the data. ... View more

First of all, you do not need to calculate 77 different OD matrices.  Just load the forest stands as origins and all the mills as destinations.  You will get one OD Line from each origin to each destination.  That said, depending on how many forest stands there are, it could be a very large OD matrix.  If you start running out of memory on Solve, you'll want to chunk up the problem into smaller pieces, similar to what you're already doing. You can do the following to get the output Lines table so you can use it in other tools like AddJoin: # ODLayer is the NA Layer object returned by getOutput(0) ODLayer = arcpy.MakeODCostMatrixLayer_na(inNetworkDataset, outNALayer_OD,                                 impedanceAttribute, BufferSize, "",                                 accumulate, uturns, restrictions,                                 hierarchy, "", PathShape).getOutput(0) # To refer to the OD sublayers, get the sublayer names. if ArcVersion in ["10.1", "10.2"]:     naSubLayerNames = arcpy.na.GetNAClassNames(ODLayer) elif ArcVersion == "10.0":     naSubLayerNames = dict((sublayer.datasetName, sublayer.name) for sublayer in  arcpy.mapping.ListLayers(ODLayer)[1:]) points = naSubLayerNames["Origins"] stops = naSubLayerNames["Destinations"] lines = naSubLayerNames["ODLines"] # Make layer objects for each sublayer linesSubLayer = arcpy.mapping.ListLayers(ODLayer, lines)[0] pointsSubLayer = arcpy.mapping.ListLayers(ODLayer, points)[0] stopsSubLayer = arcpy.mapping.ListLayers(ODLayer, stops)[0] # ... use sublayers in other tools Use the Origin_ID and Destination_ID fields in the output Lines to join back to the ObjectID field of Origins and Destinations ... View more

I think an easier thing for you to do would be to change the impedance attribute to distance and solve the service areas for distance instead of time.  If you want to make a 10-minute service area, and you assume that pedestrians travel at 3mph, make a 0.5-mile service area.  No need to change any evaluators or worry about historical traffic or fallback times. "Walking" is a restriction attribute that simply prohibits travel on certain roads that are not appropriate for pedestrians. ... View more