Latest Contributions by MichaelRice

How exactly are you setting this field value to null? It works fine for me in ArcMap. If you are doing this programmatically, what programming language is this in and how are you doing it (i.e., can you show the specific lines of code)? ... View more

The error you are getting is just a high-level error intended to let you know that something went wrong in the solve. If you want more specific information about what went wrong, then try iterating through the messages populated in the GPMessages object you passed to the solve method. If an error occurs, the solver will typically populate the GPMessages object with more specific details of the problem (since, for example, there may be many invalid field values in your input NAClasses), and then it errors out with the generic error message you referred to. ... View more

(the solver descends and ascends when the hierarchy button is on!!!). Shouldn't it have failed??.... Not necessarily. Do not think of it as "ascending" or "descending", as this is where the confusion typically comes from. Rather, think of it as applying a filter during the search, which can be progressively restricted. Let's call this filter value f. During the search, any edge which is reached for the first time with a hierarchy value > f is ignored/restricted. For example, as the search starts out, the filter is very relaxed (e.g., f = 5), meaning that the search will allow paths that cover *all* levels of the hierarchy (1 through 5 in your case). After the search reaches some number, k, of entries into the next level higher than the current value of f (this would be level 4 at this point), then the value of the filter is decreased by one (e.g., f = 4). Now, the search will only allow paths on edges from levels 1-4 (and level 5 edges will be ignored from that point on). This process iterates until the two searches meet to establish a valid path, assuming one exists. Note that this meeting point does not necessarily have to occur on the highest level of the hierarchy. For example, in your case, you noticed that the shortest path did not include a level 1 edge. This is likely because your stops were close enough that the shortest path did not really need to get on a level 1 edge (such as an interestate, typically). Additionally, in your example where you said that the solver "descends" and then "ascends" again (going from level 2 to level 3 and then back to level 2), it is most likely that the filter value was simply still "relaxed" enough at that point during the search (e.g., f = 3) to allow this path. Does this make sense? .... and the when we have the same start and end points and only add some barriers the solver shows an error. Why it cannot descend and ascend this time?? I cannot say for sure without seeing the exact case you are referring to, but it is likely that you have simply blocked (effectively, disconnecting) the only levels of the hierarchy that it could use to reach the destination. Remember, it was not truly "descending" before. It was just that the filter was relaxed enough to allow those lower level edges. It is possible that when the search reaches the areas which are blocked by the barriers, the filter is set too low to allow any "descent" into the surrounding area along lower-level edges, so that it cannot bypass the barriers. When I uncheck the hierarchy (in the example with barriers) the solver responds giving a solution. This is because without using hierarchies, you are performing an exact shortest path search, which will find the true shortest path (around the barriers), if one exists. There is no hierarchical filtering going on in this case, which is why the search can find the path. Please be aware that hierarchies are only used as a technique for speeding up the search times for long-distance paths. This is because most long-distance paths (e.g., Los Angeles to New York) will very quickly travel up to the high-level edges, such as interstates, and then travel along these high-level edges for most of the way, ignoring all (or most) lower-level edges. Hierarchical searches therefore attempt to mimic this travel pattern to avoid having to consider all of the possible detours along the way. This speeds up the search time considerably (but does not guarantee to find the true shortest path, since some edges are simply ignored during the search based on their hierarchy value). Therefore, for short-distance routes (e.g., local routes within a small region of a city), it may not make sense to use hierarchies (since it might force you to go out of the way to take the interstate, due to the hierarchical filtering, when there is a more direct, and shorter, path). Hopefully, this answers some of your questions. Please let me know if there are any other issues. ... View more

The on line ArcGIS help says that the solver may not find the solution and fail. When can that happen?? This can happen when one of the upper levels of the hierarchy is disconnected. Specifically, if the solver starts to filter all but the highest levels of hierarchy, but these upper levels are disconnected, then it may fail to find a path (even if there is a connecting path on some of the lower levels of hierarchy). This can usually be avoided by ensuring proper hierarchy value assignments when creating your network dataset. I mean in the first case the solution follows the 5th hierarchy then converts to 4th then 3rd then 2nd then goes to the 3rd again then again to the 2nd...why if the Hierarchy is checked on!!?? I don't really understand exactly what you are asking. Can you try to clarify? Only once the search has explored "far enough" will it start to filter all but the higher hierarchy levels. Specifically, the search begins by allowing all hierarchy levels to be explored. Once it has reached a certain number of entries from its starting point into the next higher level, it will begin filtering all lower levels. This process iterates, progressively moving up in the hierarchy for long-range routes. However, if your stops are relatively close together (or if there are not very many nearby entries into the next level), a path may be found before the search starts to filter out the lower levels of your hierarchy, which can give the results you are seeing (i.e., where the hierarchy values along the path do not always simply monotonically decrease and then monotonically increase). Does this answer your second question? ... View more

Make sure that the Network Analyst extension is enabled. From the ArcMap main menu, choose Customize > Extensions... and make sure to check on the Network Analyst extension from the dialog box. This will enable Network Analyst in ArcMap. Now, when you add a valid network dataset to ArcMap, the functionality should be enabled on the Network Analyst toolbar. ... View more

Another possibility is that your impedance attribute is now returning a cost of zero for some (or all) of your edges. With zero-cost edges, *any* path will be a "shortest" path, and thus you may get these winding paths such as you see here. I have seen "haywire" results like this many times, and this is usually the reason. Please check your impedance attribute values for the edges along the given path (using the Network Identify tool), and if this is indeed the problem, update your attribute evaluator to return the correct (non-zero) values and rebuild. ... View more

The simplest way might be to build a Geoprocessing model, which takes the input origin and destination addresses and processes the rest. The suggested workflow would seem like the perfect candidate for such a GP model. ... View more

This is quite an interesting use case. I think there is a better solution for you than trying to use a hierarchy attribute, as this is not really how they were designed to work. Below is a suggested formulation for solving this particular problem. ...we are attempting to create routes which get to a state jurisdiction route as quickly as possible and then stay on state jurisdiction routes for as long as possible, even if an intermediate portion might allow for somewhat faster travel. This would suggest the creation of routes from a starting point, s, to a terminal point, t, broken up as follows: s------>x------------------------>y------>t The goal is to minimize the distance from s to x (its nearest entrance to state roads) and from y to t (where y is t's nearest exit from state roads), regardless of the shortest path cost between x and y. Therefore, you can solve this as follows. Create a new restriction attribute in your network dataset called something like "State roads only", which returns false for state-jurisdiction roads and true for non-state-jurisdiction roads (this restriction effectively restricts all but state roads from travel, since true means restricted in the context of restriction attributes). Precalculate and store all entrance points onto your state roads. Call this set X. Similarly, calculate and store all exit points from your state roads. Call this set Y. Note that X and Y may have some members in common. Now, for a given s-t route pair, create two Closest Facility layers. In the first, load s as the incident and set X as the facilities. Solve to find the single closest facility, x in X, based on traveling from incident to facility (this is an option on the analysis layer property pages). In the second layer, load t as the incident and Y as the facilities. Solve to find the single closest facility, y in Y, based on traveling from facility to incident. This gives you the shortest path from s to x and from y to t, as defined above. Then, you can create a new Route analysis layer to find the shortest path from x to y, making sure to turn on your "State roads only" restriction attribute for this solve, so that this path can only travel along state roads. You can combine the three separate subpaths to form your final, desired path. Of course, you can further streamline this process if you have many such s-t pairs to process simultaneously, but hopefully you get the point. Please let me know if you have any questions about this suggested approach. ... View more

It is my understanding that once a route hits the highest level of hierarchy, it should not leave that level. This understanding is close but not 100% correct. Only once the search has explored "far enough" will it start to filter all but the higher hierarchy levels. Specifically, the search begins by allowing all hierarchy levels to be explored. Once it has reached a certain number of entries from its starting point into the next higher level, it will begin filtering all lower levels. This process iterates, progressively moving up in the hierarchy for long-range routes. However, if your stops are relatively close together (or if there are not very many nearby entries into the next level), a path may be found before the search starts to filter out the lower levels of your hierarchy, which can give the results you are seeing. Hierarchy attributes are intended primarily for speeding up the results of long-distance routes, without losing too much accuracy (i.e., we still want to find the shortest path possible). Can you offer some explanation as to why you are using this particular hierarchical formulation (i.e., using state-jurisdiction vs. non-state-jurisdiction roads)? What is the primary distinction between these two classes? What is the average distance of the routes you are trying to calculate? ... View more

This issue can be due to several possible reasons: Your origins (and/or destinations) are located on restricted elements. At the ArcGIS 10 release, we have provided functionality to avoid locating your points on restricted elements. There is no valid path in your network dataset from some (or all) of your origins to some (or all) of your destinations. This can be due to disconnected parts of your network from using restriction attributes or from having bad topology in the network dataset. There are other possible reasons, but these are generally the most likely cases, so let's start there first. Where is your network dataset data coming from? I would first suggest turning off all of your restriction attributes and trying to re-solve the analysis to see if restrictions could be part of the problem. If this doesn't help, then it is likely a topology problem in your network data. Let me know, and we can proceed from there. ... View more

Network datasets in a 9.3 ArcSDE database do not support partial rebuilds, which could explain why your build times take so long, even for a single feature change. You should upgrade your network dataset to 10 in order to get the partial rebuild functionality. ... View more

If you are editing only one feature, then (at ArcGIS 10) you should be able to do a partial rebuild that only rebuilds the parts of the network dataset associated with that changed feature (which should typically be very fast). Therefore, you should not likely be seeing 30-40 minute build times in this case. How are you editing this single feature? Are you making any other changes to the network dataset at all (e.g., changing attribute settings, etc.)? ... View more

Are you just changing restriction attribute values? If so, are you changing them for all of your source features? What is the use-case scenario for why you are changing them daily? If you wish to represent restriction attributes which are truly as dynamic as your scenario seems to suggest, without rebuilding the network dataset each time, then you can use a non-cached attribute evaluator to calculate the restriction attributes dynamically at solve time, as needed. This would not require a rebuild each time you update the values dynamically, as the rebuild process is only necessary for cached attribute values (such as those based on field evaluators). This is because attribute values for non-cached evaluators are not built into the network dataset. Rather, they are dynamically evaluated at solve time. Examples of non-cached attribute evaluators would be a VB-Script evaluator, a function evaluator, or a custom evaluator (created using custom programming). VB-Script evaluators are simple to setup and use, but can be slow (and you are still somewhat limited in the data you can provide to them). Function evaluators for restriction attributes are limited to simple relational logic based on attribute parameters or constants. If you are trying to read custom data from some dynamic data source or you require advanced evaluation logic, and you wish to maintain relatively good performance, then I would suggest that you consider creating a custom-programmed evaluator for your purposes. I can provide you with some examples of custom evaluators, if necessary, once I know more about whether this is the best option for you, based on your responses to my earlier questions. ... View more

Okay, well I can't be sure, but we seem to have at least identified that the problem (at least for part of what you discussed above) appears to be with one or more of your input stops. There could be several possibilities here: If you are giving each stop a RouteName field value, then it could be that these field values are not identical. If you are trying to assign them to an explicit RouteName, please look at these field values in your loaded layer and make sure these are consistent. If you are assigning time windows to some of your stops, please make sure that these values are valid. For example, the time window start cannot be after your time window end. Your location field values are incorrect for one or more of your stops. How are you loading your stops into your layer file before you see this error? If none of these suggestions help, and you are unable to see any potential issues with your stops' field values when you see this error message, then I would advise you to go through ESRI Technical Support, so that we can better track down this problem. ... View more

I added the code and tested with the dataset I sent to you. The message I am getting is that - "Solve required two valid stops". Okay, now we are getting somewhere. This means that there is something wrong with one or more of your stops. Either you didn't load in more than one stop, or one of your stops is unlocated or perhaps located on a restricted element (depending on the restrictions you are applying). Is this the exact error message you are getting? I do not think we have an error message in our system that is worded exactly as you have written, but we do have one that is similar: "Need at least 2 valid stops". Can you please verify your exact error message for this case? Also, you should take a look into the data you are loading into your stops and make sure they have valid field values after loading. If they do, and there is more than one stop being loaded, then turn off your restrictions to see if this is what was invalidating some of your stops. If that is the case, then at 10.0, you have the option to avoid locating on restricted elements, which could help. Let me know what you find, and we can proceed from there. I tested with another dataset, I got message " Solve failed without any GPmessages". I assume that you placed Patrick's suggested code in the "catch" part of the try/catch block, correct? Otherwise, if the solve is successful, and there are no GPMessages, then executing Patrick's code outside of the catch block would indeed say "Solve failed without any GPmessages". If this is actually within the catch block, then the solve did throw an error, but did not enter any GPMessages. Try checking the message associated with the actual exception being thrown/caught (this is not in the GPMessages object). Below is some sample VB.NET code for catching and reporting an exception's message: ' Give user information about an exception.  Try       ' We will purposely create a File Exception for the       ' purpose of this example. We will be invoking the exception       ' by providing a path of an illegal form.       Dim fileContents As String = System.IO.File.ReadAllText("iShouldn'tWork :)")  Catch ex As Exception       ' ex.ToString will give the user a large technical dump.       MessageBox.Show("ToString: " & ex.ToString)       ' ex.Message will give the user a brief, more user friendly error message.       MessageBox.Show("Message: " & ex.Message)  End Try If you changed datasets, but did not change your solver settings (e.g., impedance name, restriction names, accumulate attribute names, etc.), then these settings may not match appropriately with the attributes available in your other dataset. This may explain this particular error. Please investigate further (as best you can) and let me know. ... View more