POST
|
Hi Nathan. Unfortunately, you won't be able to produce directions directly from your linear referenced routes. Directions draw from data in a network dataset and are produced from a route solved using one of the Network Analyst tools. The Directions need to know network-specific information, such as the streets that were used by the route, the street names, how long it takes to travel across the streets, etc. The linear referencing tools don't have any connection to the network dataset, so none of this information is available to draw from. What's the overall goal of your project? If you describe it in more detail, maybe I can help you find another solution.
... View more
01-09-2014
06:30 AM
|
0
|
0
|
795
|
POST
|
Here are a few things to check: - Did you select "Use Time" and choose a time of day for your analysis? The transit part of the network won't be used if you don't select a time of day. - If you're using specific dates, does your date fall within the date range of the GTFS data? Open the calendar.txt file to see the date ranges covered by your GTFS data. - Did you remember to run Step 4 of the tool (Get EIDs)? - Did you rebuild the network after you ran Step 4? If so, you will need to run Step 4 again. - Did you set up your evaluators correctly (see the user's manual) - When you made your network, did you use Override for the connectivity policy on the Stops_Snapped2Streets? These stops will connect to vertices in the streets. If your streets have End Point for connectivity and you don't select Override for Stops_Snapped2Streets, they don't actually be connected in the network. Note: If you change this, you will have to rebuild your network and run Step 4 again. Here's how I usually debug transit problems: - Zoom in to a single transit line. - Create a new route layer and add stops on the street near each end of that transit line. - Use Network Identify to get the SourceOID or EID of that transit line. - Open TransitScheduleTable and search for that SourceOID or EID. You'll find a start time when this edge should be traversable - Set your route layer's start time to a time just before the time when the edge should be traversed and solve the route layer. - Check to see if it uses the transit line instead of the street. You might have to adjust the start time. Check all the minutes surrounding your expected start time. If it never uses the transit lines, something is probably wrong with your network. After you've checked all the things I mentioned above, if it's still not working, you can post your data, and I'd be happy to take a look at it.
... View more
12-20-2013
05:47 AM
|
1
|
0
|
246
|
POST
|
This isn't a Network Analyst question, so I've redirected your post to Spatial Analyst. Hopefully someone here will be able to help you or redirect you to someone who can. Good luck!
... View more
12-16-2013
06:17 AM
|
0
|
0
|
321
|
POST
|
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
12-10-2013
06:21 AM
|
0
|
0
|
244
|
POST
|
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
12-10-2013
06:10 AM
|
0
|
0
|
951
|
POST
|
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
12-10-2013
06:07 AM
|
0
|
0
|
273
|
POST
|
Hi. Here's what's going on: When you set up your network dataset, a cost attribute was created called Cost with units of kilometers. The Evaluators for a cost attribute tell the network how to calculate the impedance on each network edge. So, the Cost attribute should have an evaluator that tells the network how many kilometers each edge has. Your Cost attribute's evaluator just gets this value from the "cost" field in the input roads2 feature class. However, if you open the attribute table of roads2, the value of everything in the "cost" field is 0. Consequently, the network thinks that every edge is 0 kilometers long. Consequently, it doesn't matter which roads you take to get from Point A to Point B because the result is 0 kilometers no matter what. In order to solve your problem, you need to create a better network dataset with a good cost attribute. Since you've said you're not very experienced with Network Analyst, I think your best bet is to go through some of the tutorials (http://resources.arcgis.com/en/help/main/10.2/index.html#//00470000005r000000). Start with the "creating a network dataset" one and make sure you really understand what's going on with the attributes and evaluators. If you're still having trouble after working through the tutorials, post again, and we'll help you out.
... View more
12-06-2013
12:02 PM
|
0
|
0
|
677
|
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
|
677
|
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
|
677
|
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
|
579
|
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
|
853
|
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
|
853
|
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
|
853
|
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
|
481
|
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
|
2003
|
Title | Kudos | Posted |
---|---|---|
2 | 08-13-2024 09:47 AM | |
1 | 08-08-2024 03:14 PM | |
1 | 07-02-2020 11:57 AM | |
1 | 06-11-2024 09:30 AM | |
1 | 06-13-2024 06:10 AM |
Online Status |
Offline
|
Date Last Visited |
6 hours ago
|