|
POST
|
Okay, then let's try a different approach. The other technique is a little more involved, so I would ask that you first view the Network Analyst presentation from the 2007 ESRI Developer Summit: http://edn.esri.com/index.cfm?fa=media.detail&media=74 This details a lot of the basic Network Analyst API, as well as some of the most common Network Analyst programmatic workflows. When watching this, pay special attention to the part (about 1/3 of the way through) where we discuss finding NALocations (the slide title is "Find NALocation Using NALocator"). Here, we discuss how to use the INALocator.QueryLocationByPoint method to locate an individual input point on the network. This method returns a parameter called 'outputPoint', which represents the actual point location on the network that your input point references (this is essentially the "snap point" you are looking for). On the next slide (titled "Create New NALocationObject"), we then show how to use this information to create a new feature in your analysis layer. If you want to enable snapping, then you can simply replace the following line of code... stopFeature.shape = inputPoint; ...with this line of code... stopFeature.shape = outputPoint; ...to enable snapping. Let me know if you have any related questions.
... View more
08-17-2010
08:16 AM
|
0
|
0
|
1649
|
|
POST
|
Feel free to post any of your code in this thread for further discussion. The most basic programming pattern used to load data into a network analysis layer is to use the NAClassLoader. See here for more detail and some simple code samples: http://resources.esri.com/help/9.3/ArcGISDesktop/ArcObjects/esriNetworkAnalyst/NAClassLoader.htm The link above will provide code samples in several programming languages showing the most basic way to use the NAClassLoader for loading data from an input source feature class. If you want to enable snapping, then use the INAClassLoader2 interface (look under the 'Interfaces' section at the above link, and click on 'INAClassLoader2' to see more information). In your case, if you want to snap directly to the network, then simply set INAClassLoader2.SnapToNetwork = True before calling Load.
... View more
08-16-2010
01:14 PM
|
0
|
0
|
1649
|
|
POST
|
How are you doing this programmatically? Are you using the Network Analyst API (e.g., the NAClassLoader or NALocator objects)? If so, I can show you how to do snapping. If not, please let me know what API you are working with.
... View more
08-16-2010
08:28 AM
|
0
|
0
|
1649
|
|
POST
|
I assume that, when you say "the system cannot establish the connectivity", you mean that the Route solver is unable to find a path, correct? If so, this could be for several different reasons, the two most likely of which would be the following: You have connectivity issues in your dataset. If the network is small enough, you can try troubleshooting this possibility by using the Network Identify tool on the Network Analyst toolbar to click on the starting edge (or junction) and try finding a simple path to the destination by progressively following the adjacent elements shown by the identify dialog. If there is no such path, then there are problems with your connectivity. The edge (or junction) on which you placed one of your stops is restricted or has a negative cost attribute value. Check to see which restrictions attributes you have turned on for your analysis, and, using the Network Identify tool, check to see whether the starting/ending edge (or junction) is restricted for any one of these attributes. Also, check to see if its associated cost attribute is negative. If either of these is the case, this is why you cannot find a path. Let me know what you find for the two possibilities above, and we can proceed from there. Also, if you could provide the exact error and/or warning messages you are receiving, that would be helpful in figuring out the problem as well.
... View more
08-16-2010
08:23 AM
|
0
|
0
|
1093
|
|
POST
|
Here is what I would suggest: Create two fields in your streets feature class called "FT_FuelConsumption" and "TF_FuelConsumption" to represent the fuel consumption for both directions (From-To and To-From) of a given street, respectively. Calculate these field values (e.g., using a VBScript formula in the Field Calculator) based on whether they have a positive or negative slope for that direction. Create a cost attribute called "FuelConsumption" in your network dataset. Specify the "FT_FuelConsumption" and "TF_FuelConsumption" fields as the sources for this attribute for your streets in the From-To and To-From directions, respectively. Solve your route as before, but specify to accumulate "FuelConsumption" (this can be specified from the Accumulation tab on your Route analysis layer property pages). You can then open your Routes attribute table after a solve and see the total fuel consumption in the "Total_FuelConsumption" field. Let me know if you have any further questions.
... View more
08-11-2010
08:29 AM
|
0
|
0
|
1346
|
|
POST
|
Why not store the positive/negative slope information on the edges themselves (e.g., using a descriptor attribute)? Having +/- slope information stored on the junction can be misleading since each junction can connect to multiple edges, some of which may have positive slope, and some of which may have negative slope. Please let me know if I have misunderstood your use case.
... View more
08-11-2010
07:56 AM
|
0
|
0
|
1346
|
|
POST
|
Yes, this will only be possible at the 10 release, since that is when we established the concept of time-dependent evaluators. To get started, you will need to familiarize yourself with the basic network dataset evaluator concepts: http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#/Types_of_evaluators_used_by_a_network/00470000000n000000/ Next, you will need to review one or more of the existing network dataset custom evaluator samples we have available online: http://help.arcgis.com/en/sdk/10.0/arcobjects_net/conceptualhelp/index.html#//0001000001q2000000 http://help.arcgis.com/en/sdk/10.0/arcobjects_net/conceptualhelp/index.html#//00010000036w000000 These will help you get familiar with the necessary API, evaluator framework, and workflows. Once you understand those samples, then you will need to create your own custom evaluator sample, similar to the developer samples. Except, in your case, your new evaluator will now need to implement a new interface that was made available at 10: ITimeAwareEvaluator. This interface can be seen here: http://help.arcgis.com/en/sdk/10.0/arcobjects_net/componenthelp/index.html#/ITimeAwareEvaluator_Interface/0025000008p8000000/ By implementing this interface, you are indicating to the Route solver that the attribute it is associated with is "time aware". This will cause the Route solver to pass the "arrive time" at a given network element during the search to the ITimeAwareEvaluator.QueryValueAtTime method on your custom evaluator. This allows you to return the appropriate delay, based on the current arrive time at that element relative to the available bus departure times in your schedule.
... View more
08-10-2010
08:02 AM
|
0
|
0
|
951
|
|
POST
|
I see now what you are asking for. You are essentially wanting to build the bus schedules into your analysis, so that if the route arrives at a bus stop early, it must wait until the next scheduled bus departure. Unfortunately, this is not something that is currently supported out-of-the-box in Network Analyst. However, there are plans to address this functionality in a future release. In the meantime, you should be able to achieve this functionality yourself at the 10 release by programming a custom, time-aware network attribute evaluator, and making use of your bus schedule(s) in the evaluator logic. This would, of course, require you to be very familiar with our low-level ArcObjects API for the network dataset, and it would be no trivial task. Let me know if you are interested in doing this programmatically, and I can offer some initial direction to get you started.
... View more
08-09-2010
10:57 AM
|
0
|
0
|
951
|
|
POST
|
Does anyone know of a way to limit the amount of turns (in reality; bus transfers) that the route takes to, say, 2 transfers? There is currently no way to directly enforce any hard constraints on the number of turns or "transfers" taken by a path in the Network Analyst solvers. However, as mentioned in the previous response, you can penalize such "transfers" to limit the possibility that they might be taken. For example, you can create turns for all transitions from a road line to any adjacent bus lines (connected via a bus stop), and vice-versa. These turns would represent the "transfer" of getting on or off a bus, respectively, at a bus stop. You could then penalize these turns as you see fit, to represent an appropriate delay.
... View more
08-09-2010
09:18 AM
|
0
|
0
|
843
|
|
POST
|
The article you suggested doesn't explain how to implement the elevation field. Please see the Network Analyst tutorial. It walks through the creation of a network dataset which uses elevation fields. I showed you the earlier link mostly to give you a discussion of what the elevation fields are used for, since this is not really fully discussed in the tutorial. Now that you understand their purpose, perhaps the tutorials will be sufficient. Is there a format the data must be in? Yes, the elevation fields must store integer values. Since your data is exact height, it is probably some floating point representation, which is not allowed. You do not need exact heights. You really only need logical elevations (e.g., 0, 1, 2, etc.) to indicate that junctions at the same logical level connect. ...is the algorithm used by ArcMap Dijkstra's algorithm? It is a variant of Dijkstra's algorithm. Please see the following link for more details: http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#/Algorithms_used_by_Network_Analyst/004700000053000000/
... View more
08-09-2010
09:07 AM
|
0
|
0
|
1681
|
|
POST
|
Mike, Well, like I was saying, there is certainly an algorithm for that. In graph theory parlance, what you are asking to do is to determine the biconnected components of your graph (i.e., network). See here for a brief discussion: http://en.wikipedia.org/wiki/Biconnected_component The so-called cut vertices shown in the graphic at the link above represent the only entrance and exit vertices into each respective biconnected component (what you have been calling "loop systems") in the graph. Unfortunately, you would need to be familiar with standard graph traversal algorithms, as well as our own ArcObjects API, to implement such analysis to identify biconnected components on our network datasets. You can, of course, do a search on this concept to find more relevant and detailed information. However, while the examples you have provided in your screenshots appear straightforward, this concept is not as simple or intuitive as it might seem on the surface, especially when considered in the context of your density analysis task. For example, consider that we have a very large graph, with only two separate biconnected components ("loop systems"), each with equal number of edges and junctions, and each connected by a single "bridge". That is, all paths from one component to the other must always pass across this bridge. Both are loop systems, but both make up roughly half the size of your full network/graph. Which of these "loop systems" would you be willing to drop from your density analysis? One? Both? Neither? As you can see, it appears intuitive when you notice that many of these components are merely very small neighborhoods which are connected to the main network via only a single vertex or edge. However, what happens to your analysis when the components represent a more significant portion of your network? How representative would your analysis truly be if you ignored such a large portion of the network? Do you see what I am getting at? I realize that this probably gave you more questions than it did answers, but I just wanted to point out that it may not be as straightforward as it looks. Is there perhaps some way to simplify which junctions you wish to remove from your analysis? For example, what if you only remove dead-ends? Would this somehow invalidate your results or would it still be acceptable?
... View more
08-05-2010
11:43 AM
|
0
|
0
|
1560
|
|
POST
|
...they take a left turn onto a bridge that is actually overhead. I know that I will need to include turning policies to prevent this but I am unsure how to do it. If you wish to establish better connectivity for such overpass/underpass scenarios in your network dataset, you can use elevation fields instead of turn restrictions. Elevation fields are discussed in the online Desktop Help here: http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#//004700000009000000.htm As for hierarchies, your network seems relatively small, so I do not know if you will truly need hierarchies for your purposes. Hierarchies are primarily used to speed up shortest path calculations on very large network datasets (e.g., the US road network with 50+ million edges). They are not intended to provide more "accurate" paths. In fact, using hierarchies can result in suboptimal paths, since they are based on a heuristic algorithm. In contrast, without using hierarchies, you are guaranteed to find the optimal path (although it may take longer to solve for very large networks). Since your network dataset is so small, I would suggest assessing your current shortest path runtimes and solution quality first before worrying about trying to establish hierarchies. If you are doing exact shortest paths (i.e., no hierarchies) and your path is taking residential roads, it is because this is the true shortest path, based on the data you have provided. If you feel that this is incorrect, then you will need to somehow adjust the costs of your network to better reflect the paths you think the solver should find. The output paths will only be as good as the input data you provide. Please let me know if you have any further questions.
... View more
08-05-2010
09:40 AM
|
0
|
0
|
1681
|
|
POST
|
...when I solve the OD Cost Matrix all I get are straight lines, which leads me to believe that the points and lines aren't talking to each other. I am not sure what you mean by this. The OD solver will always produce straight lines. The lines are merely meant to indicate that a shortest path was found between the origin and destination pair connected by the line. You can look in the Lines attribute table to see the resulting shortest path cost (based on network distance and not straight-line distance) for each specific line's origin/destination pair. If you wish to see the actual shortest path between each origin/destination pair, and not just the shortest path cost, then you can use the Closest Facility solver instead. Just load your origins as Incidents and your destinations as Facilities (make sure you specify 'Travel From: Incident to Facility' on your analysis settings for the Closest Facility layer; this can be done from the layer's property pages). You must also specify the number of Facilities to find for each Incident (the default is 1). However, since you will have only one Facility (i.e., destination) in your case, then the default should be okay. I am just letting you know in case you decide to add more Facilities later on. As for your question about hierarchies, how many edges and junctions are in your dataset? If the dataset is small enough, you probably won't need hierarchies. Let me know, and we can proceed from there.
... View more
08-05-2010
08:13 AM
|
0
|
0
|
1681
|
|
POST
|
Martin, The Route solver algorithm is based on a variant of the Dijkstra algorithm. The Prim and Kruskal algorithms are for finding minimum spanning trees and are not applicable to finding shortest paths.
... View more
08-05-2010
07:54 AM
|
0
|
0
|
625
|
|
POST
|
Mike, There are algorithmic ways of doing what you are asking for, but there are no existing out-of-the-box tools in Network Analyst to do this. Could you provide some use cases for why you need this functionality? Perhaps providing some additional context for what you are trying to do will allow me to better help you arrive at a suitable solution. As for the link you provided in your original post, this appears to be referring to something different than what your post suggests. The linked thread is referring to loop edges, which are just single edges which have the same starting and ending junction (i.e., the edge loops back to its origin). You seem to be asking to detect entire sections of your network which can only be entered or exited via one junction (at least, that is what your image suggests). Can you verify this or elaborate further?
... View more
08-05-2010
07:49 AM
|
0
|
0
|
1560
|
| Title | Kudos | Posted |
|---|---|---|
| 1 | 01-06-2015 01:03 PM | |
| 1 | 11-16-2011 10:41 AM | |
| 1 | 10-15-2010 12:32 PM | |
| 1 | 12-02-2011 06:41 AM |
| Online Status |
Offline
|
| Date Last Visited |
11-11-2020
02:23 AM
|