Latest Contributions by MichaelRice

What is happening in the SetSolverSettings function? Are you calling UpdateContext after changing your solver settings (I don't see any calls to this in your document)? If not, you certainly should be. If you are indeed calling this before calling solve, then I would ask for you to package up your code and maybe a small sample dataset and send it to me to look at. You may reach me at mrice@esri.com. If you would rather track this through official channels, then sending this issue to ESRI Technical Support would work as well (and you may be able to get a faster response, as I don't know exactly when I would be able to look into this in further detail [although I will certainly try]). ... View more

Looking at your last email, the error appears to be coming from a call to some IArray variable. This is likely coming from one of the IStringArray variables passed to the solver (e.g., for accumulate attribute names, etc.). In your code, I notice you have the following: ' Dim AccumulateAttributes As IStringArray 'changed 09_16 Dim AccumulateAttributes As StrArray Is there a reason you recently changed this code from using the IStringArray interface? Perhaps this is somehow part of the problem. Can you change the code back to how it was or comment out your use of the accumulate attributes altogether to see if this is the issue? ... View more

Is this the only message in the GPMessages object, or just the first message? If there are more, can you report those as well? ... View more

I see in your code that you have a try/catch block around the solve and you report the first GPMessage returned by the solver upon failure. Have you checked to see if there are any other messages in the GPMessages object? There can be multiple messages, and there may be more detailed information in this object that will help to narrow down the problem. Try this first, and we can proceed from there. ... View more

Thomas, I am glad to hear that you finally got this working. Please feel free to post back here with any future updates on your project and its progress. I am interested to learn more about your unique problem, and its applications. Best of luck! Michael ... View more

Can you post your code (or at least, the portion of the code where you are getting errors)? ... View more

Any chance to get this working in 9.3? Absolutely. There are some simple code snippets showing how to do this same thing located here: http://resources.esri.com/help/9.3/ArcGISDesktop/ArcObjects/esriNetworkAnalyst/INATraversalResultQuery.htm If you use the Visual Basic version of the code linked to above, you can simply copy and paste this into your ArcMap VBA editor and run it directly from there. ... View more

Thomas, I have investigated this some more, and there actually appears to be a logic error in accumulating negative values for the Service Area solver. Therefore, it appears that your unique use-case scenario has uncovered a previously-unknown issue. Thanks for bringing this to our attention! 🙂 I have logged this as a bug, and we will take care of it as soon as possible. In the meantime, you still have valid information which you can use for your purposes. Instead of using the field values from your Lines feature class, you can use the field values from the traversal results. Traversal results are just feature class representations of the individual edges, junctions, and turns that were traversed for a given solution, and the cost information associated with them. The sample I pointed you to earlier shows how to work with traversal results to trace paths back to the source facilities for service area solutions. There is another add-in for ArcMap which allows you to automatically generate the traversal results for a given solution and it adds this information to ArcMap as new feature layers. Please see this sample here: http://resources.arcgis.com/gallery/file/arcobjects-net-api/details?entryID=C8A2186E-1422-2418-3494-48812C8DB8DE Using this add-in, you can solve your service area, then generate the traversal results in ArcMap, and look at the field values on the traversal result feature layer named "Edges". The features in this layer represent all traversed edges for your solution, and the cost field values should correctly identify any negative-weight edge traversals. ... View more

Do I have to change anything in the network properties (besides the stuff which you already told me before in the thread) for the accumulation of the fuel with negative values? You should not have to change anything. Just check on the FuelConsumption attribute in the Accumulation tab on the analysis layer's property pages. If it is not accumulating the values properly for some reason, please post an example of what appears to be incorrect. I was thinking about the option to take the distance as the impedance attribute and choose a value much higher than the car actually could drive without refueling. I then wanted to make a selection from the accumulated fuel-attribute with "to_fuelconsumption <= maximum fuel in car" This is certainly a reasonable approximation. However, please note that if you simply select those parts of the network for which "to_fuelconsumption <= maximum fuel in car", then you could run into the exact same problem I was mentioning earlier about finding infeasible routes due to having a subpath which itself exceeds fuel capacity (even if the full shortest path does not). What you really want is to find only those parts of the network which are reachable within your fuel capacity and for which no subpath from the source exceeds fuel capacity. Does this make sense? You could still do this using the Service Area solver and a slight variation of your suggested approach above (of using a length-based impedance attribute while accumulating FuelConsumption). After solve, for each element which is reachable within the fuel capacity, you would need to trace the shortest path back to the source and only if every element along this subpath is itself reachable within capacity would you select that original element. There is an older online sample (in VB6) which shows how to trace paths back to the source for service area traversal results. You can find this sample here: http://edndoc.esri.com//arcobjects/9.2/CPP_VB6_VBA_VCPP_Doc/COM_Samples_Docs/NetworkAnalyst/TraversalResult/47680c4c-c854-4a0d-b975-d27cebc3ec8b.htm ... View more

Yes, what I was suggesting should let you identify the entire range of the network which you can successfully reach within your specified fuel tank capacity. This will consider paths in all directions starting from the source, and not just a single path (I was just using the single path example to illustrate some potential problems to be aware of). For each node reachable within this capacity, this will also tell you how much fuel it took to get there. ... View more

Okay, this will require knowledge in two particular areas: The Bellman-Ford Algorithm Programming Custom Network Analyst Solvers Let's start with the algorithmic requirements. The Bellman-Ford (BF) algorithm is discussed in sufficient detail here: http://en.wikipedia.org/wiki/Bellman_Ford. If necessary, you can, of course, find more detailed discussions elsewhere on the web simply by searching for "Bellman-Ford". This algorithm provides the foundation for which you can find single-source shortest paths in graphs which may have negative weight edge costs. However, after thinking about your use case some more, I have found a potential wrinkle in using this algorithm for service areas based on fuel tank capacity. You cannot simply run the BF algorithm and then choose those nodes whose shortest path distance from your source is less than or equal to your fuel tank capacity. Consider the following problem, in which we want to find the shortest path (based on your potentially negative fuel consumption values) from some point A to some point C. Suppose that the shortest path from point A to point C travels through some other, intermediate point B. Suppose also that we have a fuel tank capacity of 20 fuel units (whatever units they may be). If we simply used the standard BF algorithm, we could potentially end up in the following scenario. The shortest path from A to C costs 10 fuel units total. This is clearly within the fuel tank capacity. However, this path is made up of two subpaths: the shortest path from A to B and the shortest path from B to C. We may have that the shortest path from A to B is 30 fuel units, but the shortest path from B to C is -20 fuel units. This, of course, gives us our total of 10 fuel units altogether, but there is one slight problem: the subpath just to get from A to B takes well over the 20 unit tank capacity, so this represents an infeasible route. That is, the vehicle could never even get to point B without running out of fuel! Therefore, it seems you will have to modify the algorithm to somehow account for this capacity. In the original algorithm (using pseudocode from the link provided above), during each iteration each edge, (u,v), is "relaxed" using the following logic: if u.distance + uv.weight < v.distance: [INDENT]v.distance := u.distance + uv.weight[/INDENT] [INDENT]v.predecessor := u[/INDENT] To account for your capacity, we must adjust this logic using some additional constraints, such as follows: if u.distance + uv.weight < v.distance AND u.distance <= capacity: [INDENT]v.distance := u.distance + uv.weight[/INDENT] [INDENT]v.predecessor := u[/INDENT] Otherwise, if we allowed to relax an edge from node u and u.distance > capacity, this could result in an infeasible solution similar to the above. This adjustment should provide you with the shortest possible path to each node, v, for which no subpath exceeds fuel capacity. Then, after running the algorithm, you should only need to select those nodes, v, for which v.distance <= capacity, and this should effectively give you your desired "service area" of nodes within fuel capacity from the source. Of course, if needed, you would then be responsible for building some form of polygon around those nodes to represent the actual area. I will leave it to you to decide how to do that. Okay, now on to the second part: programming a custom solver in Network Analyst. As I said before, this is no trivial task, but it is certainly achievable. We have provided a (simple) custom solver sample online which shows how to determine connectivity from a given set of source nodes in a graph. The sample can be found here: http://resources.esri.com/help/9.3/arcgisdesktop/com/samples/NetworkAnalyst/Solvers/CustomSolver/D463AD8F-83BE-4641-A39A-B4EA5597A7B4.htm This shows the basics of which interfaces must be supported to have your solver appropriately recognized by the Network Analyst framework, as well as some of the basics of programmatically traversing the network dataset graph representation. Reviewing this sample should be a good starting point for you, and should at least give you some initial idea of what it will take to create your own custom solver. Please let me know if you have any further questions. ... View more

Ah, I see. This is quite an interesting use-case. so is there really no possible way to get this thing worked out with the fuelconsumption as impedance attribute? Theoretically, yes; there are shortest path algorithms which will work for negative weight values (assuming no negative weight cycles in the graph). However, this would require some programming to create a custom solver within the Network Analyst framework to handle such negative values appropriately as, unfortunately, there are no out-of-the-box solvers in Network Analyst which can handle this scenario as an impedance attribute. Additionally, programming a custom solver is no trivial task. If you are interested, however, I can point you to some useful resources on this. Please let me know, and we can proceed from there. ... View more

Negative values for an impedance attribute will be considered as "restricted" by the solvers, and the solver will not be allowed to traverse an element with such negative values. This is because the search algorithm is based on a variant of the well-known Dijkstra's algorithm, which cannot properly handle negative values. Therefore, the only way to include such negative values in the results would be to use this as an accumulated attribute rather than the impedance attribute itself. Is there a reason that some of these values are negative? I would assume that fuel consumption is always a non-negative value. Am I misunderstanding something? ... View more

First, make sure your encoded file path is 100% correct (i.e., that the path you are specifying actually exists; you can check this through the debugger, if necessary, since it is based partly on the StartupPath). Second, make sure that you pass the path to the folder containing the shapefile, and do not include the name of the shapefile itself. For example, if you have a Streets.shp file in your C:\TEMP\ folder, you should pass only the path C:\TEMP\ and not C:\TEMP\Streets. ... View more

There are a couple of options here: Create a different cost attribute for each travel mode (based on their respective speeds, etc.). Then choose the appropriate cost attribute to use for your analysis based on your intended travel mode. Create a single parameterized cost attribute. That is, create a cost attribute called Time, and give it a parameter called Speed (this can be done from the Attributes tab on the network dataset creation wizard; look for the 'Parameters...' button to the right of the attribute list). Calculate the value as Time = Length/Speed. The user can change this parameter as they see fit (based on their desired mode of travel) before running any analysis, and your cost values should be adjusted appropriately. Of course, you can make this as complex as you wish by adding in other parameters, etc. ... View more