|
POST
|
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
12-06-2013
09:31 AM
|
0
|
0
|
1670
|
|
POST
|
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
12-06-2013
06:14 AM
|
0
|
0
|
1670
|
|
POST
|
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
12-02-2013
06:28 AM
|
0
|
0
|
1200
|
|
POST
|
I think you just have a typo. tableName = ["CFRoutes"] should be: tableName = subLayerNames["CFRoutes"]
... View more
11-20-2013
06:56 AM
|
0
|
0
|
1832
|
|
POST
|
Where in the code are you getting this error message? Can you post your new code?
... View more
11-19-2013
10:21 AM
|
0
|
0
|
1832
|
|
POST
|
Hi Anthony. You're close, but you need to turn your CF sublayer into a layer object. Then you can use it for input directly in other tools. tableName = subLayerNames["CFRoutes"] routesSubLayer = arcpy.mapping.ListLayers(outNALayer, tableName)[0] searchrows = arcpy.da.SearchCursor(routesSubLayer, ["ObjectID", "FacilityID", "Total_Drive", "Total_Length"]) ...
... View more
11-19-2013
07:30 AM
|
0
|
0
|
1832
|
|
POST
|
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
11-15-2013
06:21 AM
|
0
|
0
|
1065
|
|
POST
|
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
10-30-2013
08:26 AM
|
0
|
1
|
2979
|
|
POST
|
"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
10-16-2013
06:11 PM
|
0
|
0
|
1429
|
|
POST
|
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
10-08-2013
07:31 AM
|
0
|
0
|
795
|
|
POST
|
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
09-19-2013
07:04 AM
|
0
|
0
|
1429
|
|
POST
|
Hola, Ernesto. Sus paradas estan en los elementos de red restringida. En las propriedades, debe hacer clic en "Excluir elementos de red restringida." Ver cuadro. (Lo siento, mi español no es bueno.) ~Melinda
... View more
08-26-2013
07:23 AM
|
0
|
0
|
1141
|
|
POST
|
This might be a dumb question, but did you click the "Solve" button after you changed the Service Area properties? Nothing will happen if you just change the properties. You have to click Solve on the Network Analyst toolbar.
... View more
08-09-2013
07:25 AM
|
0
|
0
|
1274
|
|
POST
|
If you already have the routes on a street network (ie, you used the Network Analyst Route tool on a network dataset), you can use the Copy Traversed Source Features tool to create a feature class of the actual street segments that were traversed by the routes. You can count the number of times each segment was traversed to get the volume of cyclists on the street. You can also do some clever things with the dissolve tool to sum existing fields in the routes and such.
... View more
08-08-2013
07:15 AM
|
0
|
0
|
1853
|
|
POST
|
Hello Michelle. Were you ever able to create your multimodal network dataset with transfer penalties? I just wanted to let you know about a new prototype tool from Esri's Network Analyst team which allows you to add GTFS public transit data directly to a network dataset. You can use this network dataset with the Network Analyst tools to run time-aware analyses that incorporate the transit schedules. It is possible using this method to incur transfer penalties. You can download the toolset and instructions here: http://www.arcgis.com/home/item.html?id=0fa52a75d9ba4abcad6b88bb6285fae1 Please do not hesitate to contact me at mmorang@esri.com with questions or comments about this toolset.
... View more
07-19-2013
03:48 PM
|
0
|
0
|
643
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 3 weeks ago | |
| 1 | a month ago | |
| 1 | 02-03-2026 11:41 AM | |
| 1 | 03-16-2026 08:58 AM | |
| 1 | 02-10-2026 12:22 PM |
| Online Status |
Offline
|
| Date Last Visited |
yesterday
|