|
POST
|
Hi Laura. To change an attribute parameter on a network analysis layer in python, you can use the Update Analysis Layer Attribute Parameter tool: ArcGIS Help (10.2, 10.2.1, and 10.2.2) Alternatively, if you want a little more flexibility, you can get the layer's solver properties and set the attribute parameters on the solver properties object. Here are some relevant doc pages for this procedure (including code samples): ArcGIS Help (10.2, 10.2.1, and 10.2.2) ArcGIS Help (10.2, 10.2.1, and 10.2.2) If this doesn't suit your needs and you want a new network dataset, there are a few options: - Contact your city, county, regional, or state government GIS department to see if they have a network dataset for the region you are studying. If they don't have a network dataset, they might have a streets layer you can use to create one. - Download OpenStreetMap data for the area you are studying and create a network dataset from that. - Download Tiger streets shapefiles from the US Census Bureau and create a network dataset from that. - Purchase a Streetmap Premium network dataset covering your study area from one of the sources listed here: Product Matrix
... View more
05-12-2015
09:00 AM
|
0
|
1
|
1662
|
|
POST
|
Hello, Priyanka. Accessing the NA sublayers in python can be a little tricky. The Select Data tool is a Model-Builder-only tool. You have to play with layer objects when you're using python. The best thing for you to do is to look at the last code sample on this page: ArcGIS Help (10.2, 10.2.1, and 10.2.2) It's for the Route solver and not Closest Facility, but it's the same idea. The OD Cost Matrix and Service Area doc pages also have similar samples that might help.
... View more
04-21-2015
08:14 AM
|
0
|
1
|
3122
|
|
POST
|
Streets that are expected to connect have to have either a) and endpoint or b) a vertex on both street features at the location where they touch, depending on whether your connectivity policy is End Point or Any Vertex. Please read this doc page to understand what those mean: ArcGIS Help (10.2, 10.2.1, and 10.2.2) If your connectivity is Any Vertex and you just need to do a batch vertex insertion at locations where your streets touch, you can run the Integrate tool. Make sure you make a back-up copy of your data first, as Integrate actually modifies the input features by moving them slightly. You can set the tolerance to be small or tiny, though, so it won't move stuff much or at all and will instead just add vertices. The one problem here is locations where you have an overpass and the crossing streets are actually not supposed to connect. You might have to manually fix those areas. If your connectivity is End Point, you may have more trouble. If you split existing features down the middle so that they have end points, you risk messing up attributes that need to be carefully apportioned when the street feature gets split. For instance, if you have a field called "walktime" and you split a street that has a value of 5 minutes in the walktime field, it would be incorrect for the two split parts of the street to both have a value of 5 minutes. So, if you have End Point connectivity, you either need to split a lot of features very carefully, or you need to switch to Any Vertex connectivity and run the Integrate tool.
... View more
04-20-2015
09:59 AM
|
2
|
2
|
4379
|
|
POST
|
It's not possible to tell if your network is well connected just by looking at the junctions. You need to click on the edges with the Network Identify tool to assess whether or not it's actually connected to its neighbors. One other idea: In your Service Area settings, have you set the polygon generation settings to use Non-Overlapping polygons? If so, then the reachable area will be assigned to the closest bus stop if the area has more than one within the 800 meter break value. If a particular stop is surrounded by several other reachable stops, it could be that the reachable area assigned to that particular stop never extends beyond your 169 meters because all along its boundaries it encounters areas that are closer to other stops. The way to check if this is the case is to set your polygon settings to Overlapping. Also, what happens if you run the Service Area on just one of the problematic facilities. Do you get the same answer? Try turning on line generation to see what streets are actually showing up as reachable.
... View more
04-20-2015
09:14 AM
|
2
|
4
|
4379
|
|
POST
|
It's probably a connectivity problem in your network. Suppose you have a small chunk of your network that's disconnected from the rest of the network. If your stop snapped to a network edge in that disconnected portion, then it could be that it isn't possible to travel 800 meters. The maximum distance you could travel was 169m. Use the Network Identify tool (on the Network Analyst toolbar) to click around on the network edges in the vicinity of the problematic points. In the pop-up Network Identify box, you can see what other edges are connected to the one you clicked on, so this is an easy way to identify connectivity problems. In order for network edges to connect, there needs to be either an endpoint or a vertex on both features at the location where they touch, depending on your connectivity policy. You can read more about network connectivity here: ArcGIS Help (10.2, 10.2.1, and 10.2.2)
... View more
04-17-2015
03:53 PM
|
1
|
6
|
4379
|
|
POST
|
First question: Did you remember to "build" your network after adding in the driveways? Assuming you built the network, then it sounds like your new driveway isn't actually connected to the network. Even if the driveway is touching the street, it won't connect if there's not an endpoint or a vertex (depending on your Network's connectivity Policy) on the street feature at the location where the driveway touches it. Please read up on network connectivity here: ArcGIS Help (10.2, 10.2.1, and 10.2.2).. You can always look for network connectivity problems using the Network Identify tool (on the Network Analyst toolbar). When you click on a network edge, it will show you all the other edges that are actually connected to it.
... View more
04-17-2015
08:23 AM
|
1
|
1
|
1451
|
|
POST
|
A geometric network isn't the same thing as a network dataset. Geometric networks are usually used for utilities (power, water, etc.), whereas the network dataset is specifically for roads and used in the Network Analyst extension. Could that be the problem?
... View more
04-16-2015
09:08 AM
|
2
|
1
|
2504
|
|
POST
|
Hello, CY. At this time, there are no plans for a tool to create a GTFS dataset from ArcMap. One of the main reasons is that most of the data included in the GTFS dataset is not inherently geographical. stops.txt is the only required file that contains any geographic information at all (the stop locations). The only other file that includes lat/lon points is shapes.txt. The rest of the files are a large set of related tables containing information about the schedules. We don't have any tools to help with scheduling, and table manipulation is probably easier outside of ArcMap.
... View more
04-13-2015
08:35 AM
|
0
|
0
|
1890
|
|
POST
|
Hello Aaron. First, make sure your new roads are actually snapped to the existing roads. If there is even a tiny gap, they will not be connected in the network. Next, check your network's connectivity policy. If the connectivity for your streets is "End Point", then the new streets must snap to end points of the existing streets in order for them to connect (and the Integrate tool won't help here). If you want your new street to be connected in the middle of an existing street, then you need to split the existing street, and also be careful to fix any attributes in that existing street feature that might have gotten messed up due to the split. If your connectivity policy is Any Vertex, then then streets don't have to touch at end points, but there does need to be a vertex on the existing street at the location where the new street touches it. However, the Integrate tool should have taken care of this, so I suspect that the problem is one of the others I mentioned above. To learn more about network connectivity, please read this page in the doc: ArcGIS Help (10.2, 10.2.1, and 10.2.2)
... View more
04-05-2015
02:53 PM
|
0
|
0
|
2111
|
|
POST
|
You can write such a script using a Geometry Polygon object and some search cursors. See the code sample at the bottom of this page: ArcGIS Help (10.2, 10.2.1, and 10.2.2)
... View more
04-02-2015
11:08 AM
|
0
|
0
|
5238
|
|
POST
|
Hi Yann. Actually, you should be able to solve your problem with Closest Facility. You can just turn the output shape generation off (the No Lines option), and this will eliminate the time and memory overhead of storing the route geometries, which you don't need. You can use the other settings to control the direction of travel and the number of facilities to find. If you try this and don't find our latest Closest Facility solver to be "as reliable and faster than its odl AV3 predecessor", please let us know.
... View more
03-27-2015
12:13 PM
|
0
|
1
|
1432
|
|
POST
|
Thank you so much for your input, Rell. Regarding points that still fall outside the range specified: If this is a consistent problem for you, you can just increase the search tolerance (range). Is there some other reason increasing the search tolerance wouldn't work for you? Regarding the Ignore Invalid Locations setting: The current ArcMap 10.x behavior is as follows: If "Ignore Invalid Locations" is checked True: The solve succeeds, but it throws a warning message saying 'Location "[blah]" in "Stops" is on a non-traversable network element position.' That location is simply skipped, and the route will bypass it completely. If "Ignore Invalid Locations" is unchecked False: You get the same warning, but the solve fails, and no output is produced. You can also uncheck the "Terminate on Solve Error" option. The tool now always succeeds in running, even if no output is actually produced because the solve failed. So, to summarize: Regardless of your "Ignore Invalid Locations" setting, you can always extract the features that caused the problem from the warning messages. If you want solve output to be produced, you need to set "Ignore Invalid Locations" to True. Does that answer your question? The proposed new behavior wouldn't change the "Ignore Invalid Locations" setting, but it would make it much less likely that points would be invalid in the first place. They wouldn't locate on restricted areas to start with, and if the restrictions and barriers changed after they were located, they would be relocated automatically at solve time.
... View more
03-26-2015
12:23 PM
|
0
|
0
|
1586
|
|
POST
|
Dear Network Analyst users, The Network Analyst Team would like input from those of you who work with barriers and restrictions in Network Analysis layers. Your input on the following topic will help guide our development efforts: When you use restrictions or barriers, these restrictions and barriers can sometimes conflict with locations (stops, facilities, origins, destinations, etc.) in your NA layer. For instance, a new polygon barrier might fall on top of one of your existing points, causing your Route to fail at solve time because the existing point is located on (snapped to) a restricted network edge. Similarly, if you turn on a restriction, a point might be rendered inaccessible by the restriction, causing your solve to fail. If you have experienced this behavior, please answer the following questions: Do you view this behavior as a problem? Does it annoy you, hinder your analysis, etc.? If this behavior is a problem for you, how do you currently work around or avoid this behavior (eg., loading barriers and setting restrictions before loading stops, toggling the "Exclude restricted portions of the network" button)? If this behavior is not a problem for you, do you want your solve to fail if your stops/facilities/origins/destinations are located on a restricted edge? Why? We are currently improving upon the behavior described above. In our new design, points located on (snapped to) edges that have become inaccessible due to a new restriction or barrier will be automatically relocated at solve time to the next-closest non-restricted edge (within the specified search tolerance). Solve will always succeed. You will no longer need to worry about loading your barriers and input points (stops, facilities, etc.) in a specific order. You will no longer need to relocate your input points if you change your restrictions. Conflicts will be detected and corrected automatically at solve time. Points that have been relocated will be flagged in the attribute table with a status of "Not located on closest" so that you can see which points have been affected by the auto-relocate behavior. Another field will show you the distance of that point to the network edge it was located on. You can use these fields to double-check the behavior and manually correct the locations if necessary. What do you think of this idea? Do you have any concerns? Is there anything we've missed that could further improve your workflows? Please feel free to discuss these topics here. If you would like to discuss them more extensively by phone or e-mail, please send me a private message through GeoNet, and I'll let you know how to contact me. Melinda Morang Product Engineer Esri - Network Analyst Team
... View more
03-25-2015
02:44 PM
|
1
|
2
|
5215
|
|
POST
|
Hi Simon. No, this is not possible with the OD Cost Matrix solver. The reason OD Cost Matrix is fast is precisely because it doesn't store the "traversal result", the actual network edges and junctions used. If you need to extract that information, you need to use the Route or Closest Facility solver.
... View more
03-23-2015
04:08 PM
|
0
|
0
|
649
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 2 weeks ago | |
| 1 | 3 weeks ago | |
| 1 | 3 weeks ago | |
| 1 | 06-12-2026 01:53 PM | |
| 1 | 04-21-2026 08:39 AM |
| Online Status |
Offline
|
| Date Last Visited |
2 weeks ago
|