Latest Contributions by MichaelRice

Since your case is special, in that you have only a single destination but many possible origins, I would suggest loading your many origins as Facilities and your single destination as Incidents. Then set your travel direction in the Closest Facility solver to be "travel from facility to incident". The reason for this suggestion is that the Closest Facility solver always performs a unique search from each incident until either the target number of facilities is found, or until the cutoff is reached. Even in cases where you have specified that the travel direction should be from facility to incident, the search is still done from each incident (for these cases, the solver just searches in the backward travel direction along each edge instead of in the forward direction, thus achieving the desired travel direction). Therefore, if you load your N origins as incidents and your single destination as a facility (with travel direction = from incident to facility), then this results in N unique searches, one for each of your many origins. If you instead load your single destination as an incident and your N origins as facilities (with travel direction = from facility to incident), then this results in only 1 unique (backward) search from your incident. The resulting output of the final paths are equivalent between these two setups (assuming you are solving for all paths with no limiting target facility count), but since each unique search incurs some additional overhead, it generally pays to go with the approach that results in the fewest number of unique searches. It�??s a subtle distinction, I know, but it is a crucial one that can significantly impact performance if not properly addressed. ... View more

All edge directions are referenced relative to the digitized direction of the associated source feature. Therefore, you must be aware of this direction to properly set up direction-specific attributes in your network dataset. When you specify an attribute value for your edges in your network dataset definition, you must specify an evaluator for both possible edge directions (i.e., one for "along-digitized" and one for "against-digitized"). To see this, create a new "Oneway" restriction attribute in your network dataset. From the Attributes tab on the property pages, click on the Evaluators button. In the resulting dialog, you will see two direction references for each of your polyline source feature classes: (1) From-To (this means "along" the digitized direction) and (2) To-From (this means "against" the digitized direction). Each one allows you to specify a unique evaluator for that specific direction. The most common way to support oneway restrictions in your network dataset is to have two fields in your polyline source feature class(es). One that specifies whether the feature is restricted in the from-to/along direction and one that specifies whether it is restricted in the to-from/against direction. Once you have established the proper values for these fields, you can setup an evaluator for each direction of your polyline source feature class(es) that reads from the respective field in that direction. Please see the tutorial datasets for good examples of oneway restriction attributes and how these are normally setup. ... View more

I found oneway from Network Identify tool. When I click on every road, it highlights the road with an arrow which seems should be the directions. The arrows drawn on the edges by the Network Identify tool do not represent oneway constraints. These arrows merely indicate the digitized direction of the edge's underlying source feature. More specifically, each edge in the network dataset is derived from a polyline source feature. Each polyline feature has a single digitized direction. For example, if you had drawn a polyline going from some point A to some other point B, then the network dataset would create a bidirected edge from A to B from this source feature. To determine the direction of traversal along this feature (since we could potentially travel in either direction along this edge), each edge direction is associated with the digitized direction of the feature. The direction (A,B) in this example would represent the "along-digitized" direction, whereas the opposite direction (B,A) would represent the "against-digitized" direction. The Network Identify arrows merely indicate the along-digitized direction, but this does not mean that the edge can only be traversed in this direction. This also explains why you saw the following: I found When I draw a line started from one point and ended from another ponit, the network dataset building obay this topological way as the direction of the street. Again, however, note that the arrows you are seeing are not related to any directional constraints, they merely reference the source feature's digitized direction (i.e., you can still traverse the edges in both directions, assuming you have no restriction attributes turned on). Write now there is not any warning, because during drawing new lines, I was care of the directions This is because your latest edits properly established the connectivity you were missing in your previous state, not because you drew the features in a different direction. I just want to make sure you understand this distinction, because directional constraints in the analysis can only be enforced via restriction attributes. Please let me know if there are any related questions. ... View more

If you have turned off your restrictions on your analysis layer, then the street cannot still have a oneway limitation. This is because oneway constraints are only enforced via restrictions. So if you have turned them all off, the solver will treat every edge as bidirected and would find a path if one exists. Therefore, the problem would appear to be something completely different. This sounds like it might actually be a connectivity issue. Please use the Network Identify tool to select the problematic network edges and then see which other edges/junctions are adjacent to these edges. You should be able to follow the adjacent elements using this tool to see if there is actually a connected path between your points of interest (note that this tool does not apply restrictions to determine adjacencies). If you cannot find a connected path between them, then this is indeed a connectivity issue. If that is the case, then you should investigate your connectivity policy in the network dataset properties and also check to make sure that any features you expect to connect to each other actually share a common vertex at the intended connection point (it does not suffice for features merely to touch or cross; they must explicitly share a common vertex at their meeting point in order to establish connection). Let me know what you find, and we can proceed from there. ... View more

Streets will only be treated as oneway in your network dataset if you have created a restriction attribute which constrains them to be oneway. Please look at your analysis layer's property pages and see which restriction attributes you have turned on. Then, simply turn off any oneway restrictions or other restrictions which you did not explicitly mean to use. Note that, when you are building your network dataset, the build process may automatically recognize certain fields in your source feature classes (e.g., a field named "Oneway") and create attributes based on these fields. This is only done for common attributes used in transportation analysis (such as oneway restrictions), and it may explain how you ended up with such restrictions in the first place. However, you can always simply remove them during the build process, if you like. ... View more

I can't manage to fill the intermediate ones : Attr_Minutes and Attr_Meters are always 0. For clarification, do you literally mean "you" cannot set these values (e.g., during setup of your problem) or do you mean the solver does not set these values after performing your analysis? If the latter is the case, this is because the Attr_* fields are input field values for your stops and not output field values. The accumulated costs at each stop is represented in your Cumul_Minutes and Cumul_Meters fields (as shown in your post). Have I misunderstood your question? ... View more

One likely explanation is that your impedance attribute is 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. 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. If this is not the issue, please let me know and we can go from there. ... View more

Andres, Unless you need barriers for some other purposes, you don't need to use barrier costs to limit the search to only the closest neighbors in the OD solver. You should be able to achieve this by setting a Target Destination Count (e.g., find the closest 5 for each origin) or by setting a cost Cutoff value on your search (e.g., only search up to 10 minutes away from each origin). However, even if you must still use barriers, if you are using point barriers with additive cost, then it probably won't matter too much whether the barrier points are located right on top of each other versus located just next to each other on the same edge. This is because the cost to go through these barrier points will still add up to the same amount (assuming you do need to travel through each one). Are you asking to disperse the barrier points or your other origin (or destination) points? Does this make sense? If you can further clarify your use case, perhaps we can come up with some better alternatives. ... View more

Yes, this can be done. There are two types of polygon barriers: restricted polygon barriers and scaled polygon barriers. When you create your polygon barrier, you can open its properties (right-click the barrier in the Network Analyst Window and click 'Properties...') and see its associated field values. Make sure the 'BarrierType' field value is set to 'Scaled Cost'. Then, assuming you are solving on cost attribute X, set the 'Attr_X' field value to some positive value less than 1 (e.g., 0.25). This field value sets the scale factor applied to cost attribute X for all underlying network elements covered by the polygon. Setting this value less than 1 effectively causes the solvers to "prefer" these areas more than they would have normally. You can adjust the scale factor depending on how much you wish to prefer these polygon areas. ... View more

32-bit processes can only access up to 4GB of address space. The extra RAM would only help if you wanted to simultaneously run more individual processes for increased performance. ... View more

When setting up your restriction attribute, make sure to specify its Type as "Field" and not "Script", as the field evaluator is only evaluated once at build time (and the values are cached in a table for fast lookups at query time), whereas a true script evaluator is fully evaluated every time an element is queried (which is relatively slow). When you specify the Type = Field for your evaluator, then click the Properties button on right side of the evaluators dialog to open up the Field Evaluators dialog (here you will specify some VB script code, but this will only be evaluated once at build time). The pre-logic script code should be something like the following: restricted = False If [Accessible] = "0" Then       restricted = True End If The Value expression should then simply be: restricted The code above assumes your [Accessible] field is a string field. If it is instead a numeric field, you should remove the quotes from around the 0 value above (i.e., "0" becomes just 0). ... View more

Yes, it is likely that my suggestion would require more memory than your original approach, since the solve must store all of the backward entry points for each destination. Since your recent experiments don't appear to see much difference, then perhaps your original approach is best. As for whether or not your hierarchy is accurate, the only online resource that I know of regarding ACC classifications is an ESRI whitepaper on defining hierarchies. Here is the link to the paper. Appendix B of this paper should have some useful information. Out of curiosity, is there a reason you cannot rely on the original Streetmap dataset (which already has hierarchies defined) for your analysis purposes? ... View more

I have the attribute contained in my feature class, and it has been queried out and a new feature class containing only the non-traversable segments of the network. This has been added to the network, and assigned as a restriction evaluator. You should not need to create a separate feature class to represent restricted edges. This may, in fact, be your problem. For example, suppose you have a network dataset built from some source feature class A. If you selected features from feature class A, then exported them to a new feature class B, marked them as restricted in B, and added B to your network, then the edges established by feature class A would still be traversable, even though the duplicate edges in B are not traversable, which appears to be what you are seeing. You should instead just create a field on feature class A, and then create a restriction attribute which reads this field and determines whether or not the features from feature class A are restricted. Creating a new source feature class from a subset of another source feature class will just create redundant, parallel edges. Does this make sense? ... View more

Here is one possible suggestion. Instead of iteratively solving multiple 55,000 x 100 instances, try iteratively solving it as 100 x 55,000 instances. The reason for this is that, for hierarchical searches, the process has two phases. The first phase searches backwards from all destinations until they reach the highest level hierarchy. This phase is generally very fast. The second phase searches forward from all origins until they find the points of entry into the highest level hierarchy for each destination computed in the first phase. This second phase tends to be the bottleneck in the solve as it searches much farther than the first phase. Therefore, when you solve multiple 55,000 x 100 cases, the solver is probably doing much more work per iteration in the second phase than if you instead tried solving it as multiple 100 x 55,000 cases. Put differently: in your current workflow (55,000 x 100), you are recalculating those same (more exhaustive) origin searches over and over again at each iteration, but looking for different destinations each time. It should be more efficient to only have to calculate the same (short) destination searches each time, while searching from only a few different origins each time. Does this make sense? Let me know if this helps any. ... View more

Setting up a distance attribute is the same programming pattern, regardless of the underlying network dataset type. Here is a link to some sample code for creating/manipulating VRP analysis layers, including setting of the distance attribute, etc. Sorry, it is not in Java, but the .NET programming patterns are generally the same, so you should hopefully be able to easily make the translation to Java. In general, you must set the distance attribute for VRP by specifying it as an accumulated cost attribute using INASolverSettings.AccumulateAttributeNames. ... View more