Latest Contributions by MichaelRice

I need to build a route layer within the network first before adding the locations, is that right? This depends. What type of analysis are you planning to do with your GPS points when you load them? You can load your GPS points into any one of our 6 possible analysis layers: Route, Closest Facility, OD Cost Matrix, Service Area, Vehicle Routing Problem, or Location Allocation. The one to choose depends upon your analysis needs. ... View more

Igor, You can create multiple restriction attributes (to represent different years) in a single network dataset at both 9.x and 10. There is no need to create multiple network datasets. ... View more

Is your stream layer a network dataset or something else (e.g., a geometric network)? For locating points on network datasets, you can use the 'Add Locations' GP tool (either using ModelBuilder or directly through Python), and just check/turn on the 'Snap to Network' option for the tool. ... View more

Using restriction attributes sounds like the correct approach for you. To understand how to create restriction attributes for your field values, I would suggest to work through the Network Analyst tutorial (for which you should have sample data as well). This should give you a better understanding of how to set up your network dataset for such analysis. ... View more

You must solve the route and then access the "traversal result" of the route programmatically. The traversal result is really just a collection of three feature classes: Edges, Junctions, and Turns. These three classes represent the individual edges, junctions, and turns, respectively, that were traversed to produce your current route solution. Here is a link which provides some of the relevant interfaces for programmatically accessing this information, including some sample code for retrieving and adding the traversal result feature classes as layers in your map: http://resources.esri.com/help/9.3/ArcGISDesktop/ArcObjects/esriNetworkAnalyst/INATraversalResultQuery.htm If you only have (or are only concerned about) restrictions on the edges of your network, then you can simply get the Edges feature class from the traversal result and iterate through this list of edges. To do this, you would need to get a feature cursor from this Edges feature class and iterate through the cursor. Each feature should have the appropriate field values (e.g., EID, FromPosition, and ToPosition) with which you can query the appropriate edge element from INetworkQuery, so that you can test each edge for restrictions as necessary. Note that the "position" field values, FromPosition and ToPosition, are assigned with respect to the digitized direction of the edge's source feature. You can use this information to infer the direction of the edge. Specifically, if FromPosition < ToPosition, then the edge is traversed in the "Along-Digitized" direction. If FromPosition > ToPosition, then the edge is traversed in the "Against-Digitized" direction. Please let me know if you need any further help. ... View more

One other possibility would be to simply turn off your restriction attributes in your analysis layer, and then solve to find a path (which you should be able to, assuming your network is connected). Then, simply iterate over those edges along that path to see which ones are restricted for your intended restriction attributes. I don't know if this is exactly what you are looking for, though. ... View more

May I ask why you ultimately need this information? Perhaps there is a better way to achieve your goals. The reason I ask this is because, unfortunately, the Route solver does not have such information directly available to it to report to the end user, in the event that a valid route cannot be found. During the search for a path, the solver queries the network dataset to see which edges from a given junction can be accessed. This query will only return valid edges, based on the restrictions being applied. Therefore, the solver has no knowledge of any invalid edges which were filtered by the network dataset, since they were never returned to the solver. If absolutely necessary, there are several ways you can try and get the information you are needing, each with different tradeoffs: Enumerate all edges from the network dataset and, based on the current analysis restrictions, maintain a list of which edges are restricted (i.e., which edges return "true" for one or more of your applied restriction attributes). Depending on your network size, however, this may not really be a scalable solution. Create a restriction attribute with a custom evaluator (based on custom programming logic) to act as a proxy for all of your other restriction attributes. Essentially, this would just be a single evaluator which could "forward" any restriction attribute queries on to the other restriction attributes for a given edge. If any of these forwarded calls return "true" (i.e., to indicate a restricted edge), then the proxy evaluator can simply log this edge's EID information internally. This approach is more complex than the prior approach, but it will result in only those subsets of restricted edges which actually prevented a route from being found. ... View more

You can take your park polygons and turn them into polylines using the 'Polygon to Line' geoprocessing tool (this will simply take the rings of each polygon as a polyline). Then do an intersect of your polyline features against your street features in your network dataset using the 'Intersect' geoprocessing tool (make sure to specify the output feature class type as a point feature class). This new point feature class will effectively represent all of the possible entry points into your parks along the network dataset. Create a closest facility layer, then load your survey respondents' homes as Incidents, and load your newly created "park entry points" as Facilities. Solve to find the closest facility. ... View more

I am wondering is my error caused by the fact that I snapped to edges and not just endpoints Perhaps you are correct. A couple of things to note: You must establish the appropriate connectivity policy for your network dataset. If you intend for lines to connect to one another at midspan positions (and not just at their endpoints), then you must set your connectivity policy to be 'Any Vertex' (and not 'End Point') when creating the network dataset. Assuming you have set the appropriate connectivity policy, lines will only connect to each if they share a coincident vertex. That is to say, it does not suffice for them to simply cross or touch in geographic space. They must literally have coincident vertices where they cross/touch in order to establish connectivity. This can be achieved by using the 'Integrate' geoprocessing tool, as necessary. Let me know if this helps. If not, we can go from there. ... View more

Perhaps next you could try using the identify tool to progressively find a path of adjacent elements from your starting incident to your destination facility. If there is truly no valid path (which the solver suggests), then perhaps you will see where any potential connectivity problems are coming from. If this does not help at all, then, if your data is small enough, perhaps you can zip it up and post it here for further review. I will warn you, however, that there have been problems with opening up attached .zip files on these forums, and I don't know when these will be properly addressed, so it may end up being a wasted effort. If all else fails, you can always report the issue to ESRI technical support. They can work directly with you to look at your data and help you figure out the source of the problem. ... View more

Have you tried using the Network Identify tool (on the Network Analyst toolbar in ArcMap) to click around your network dataset and see where you might have connectivity issues? For example, you can click on one of the subway routes near one of your stops, and see if there is an appropriate adjacency from the subway line (through the stop) to a walkway line. If the connectivity appears to be okay per your specifications, then try looking at the cost and restriction attribute values for some of those elements. If they have negative cost attribute values or are restricted for some set of restriction attributes that you are using in your analysis, then this could be your problem. Let me know what you find, and we can proceed from there. ... View more

Any time you make edits to your source features which participate in your network dataset, you must explicitly rebuild the network dataset to reflect those edits. This can be done by right-clicking your network dataset in ArcCatalog and clicking the 'Build' command or by calling the 'Build Network' geoprocessing tool. If you are trying to do this from a web application, then the web developer would have to programmatically provide you some way of performing the build (e.g., using a low-level call to the ArcObjects API or by calling the 'Build Network' geoprocessing tool). ... View more

Are you sure that the line features from the other connectivity groups have coincident vertices where your stops are located? It does not suffice for your stops to merely be geographically "on top of" the line features. In order for your stops to "connect" to the other line features from the other connectivity groups, the line features must have existing vertices where the stops are located along the lines. Otherwise, the stops will not be allowed to "connect" to these lines. Does this make sense? Please check this first, and we can proceed from there. If you need to establish vertices where your stops are located along the line features, you can run the 'Integrate' geoprocessing tool. ... View more

Unfortunately, I do not know of any other links to this video. Please make sure your browsers are up-to-date. If you are still having troubles viewing this and you do not feel it is because of your machine configuration, you can try contacting ESRI customer service to let them know. I am attaching a .pdf of the slides from this presentation. This is certainly not as useful as being able to see and hear the video, which offers more detailed discussions of each slide, but hopefully it is better than nothing. Please let me know if this helps. ... View more

A line feature in ArcGIS is represented by a series of explicit point coordinates (known as vertices), in a specific order. This first vertex in this order defines the "from" end of the line, while the last vertex defines the "to" end of the line. To define elevation fields, you must specify a field value for each end of the line, respectively. Therefore, you need two fields: one to represent the elevation of the "from" end and one to represent the elevation of the "to" end. You can visualize this direction in ArcMap by specifying a symbology for your lines which has arrows that follow this "digitized direction". As for connectivity polices, please see the link I provided in my second response to this thread. This discusses connectivity concepts of the network dataset, including the "Any Vertex" and "Endpoint" policies. ... View more