on May 21, 2014We try to achieve the same thing over here. Is there maybe a possibility to 'intercept' the barriers in ArcObjects code? Kind of the same way you can create a custom time aware evaluator?
Thanks,
Thibaut
Time-aware barriers and restrictions are not yet supported "out-of-the-box" for network analyst.
However, you can craft a custom evaluator to your own uses to support something similar. Here is the time-aware restriction evaluator:
http://www.arcgis.com/home/item.html?id=dc2e55c6e9c64cb19a5e8e3224032c87
That evaluator uses a CSV local to the network to apply a time window to restrict or allow traversal across network elements.
The campus data model also uses a version of this evaluator.
Hi Patrick
Can this example be translated to Java?
How do you do the registration?
Thanks
Mody
Hi, Mody! Can it be translated to Java? Yes. How do you do the registration? Good question! I have not registered a Java custom evaluator before. It should be possible, but I'm not sure how.
Hopefully, someone with more experience in Java and ArcObjects can answer for you.
I found an entry about how the RegTool had been deprecated and as of 10.0 it is recommended to put jars into well known locations. But I don't know if that will work.
Hi Patrick,
The custom evaluators (we are using these) are useful if the data is stable. But when the restrictions are changing frequently (multiple times a day) the barriers seem more appropriate, because you don't need to rebuild the network with every new restriction location.
Do you see a solution for frequently changing time aware barriers/restrictions without a network rebuild?
Thanks,
Thibaut
Hi Thibaut
The custom evaluator is reading the data in real time. It will use the current data.
You can even set different values for different times and the evaluator will read it (if you program it to do it).
Mody
That's true if you can link them to known locations (= features) in your network dataset. That's not always the case. Like when the restriction data comes from an external source.
In our case there are like 200 restrictions but 14000 possible locations. So we tried the custom evaluator, but this slows down the route solving a lot as it has many locations to check.That's why we are looking into the barriers. We know time aware barriers aren't supported at the moment, but maybe we can program it (like a custom evaluator).
Another solution is to add the restrictions in a separate layer to the network dataset and rebuild the network whenever those restrictions change. But as mentioned earlier, we want to avoid this, as the 'route solving service' will be down for a moment.
Since there are no time-aware barriers, perhaps there are a few work-arounds, as you suggest. You sound like you know what you are doing, but I'll try to give a few suggestions in hopes one triggers a good idea for you.
First off, what do your barriers represent? What is your use-case? Why do they change so often?
The custom evaluator
The benefit of the custom evaluator should be that you don't have to rebuild your network in order to update the times on the barriers. You can use Initialize or Refresh (depending on your usage) to check if the barriers files have been updated, and cache the updated restricted locations.
See the transit evaluator for a good example on caching pre-solve. You can contact Melinda Morang for a copy of the code, I think.
Like you mentioned, though, 14,000 locations is quite a few and solve will take a performance hit.
Barriers
Maybe there is a good way to set this up using barriers. Are the barriers truly time-dependent, as in, a given network element will be open until 8am, then closed from 8 am until 10am, then reopened after 10? That will be difficult to truly support with only using barriers. But you should be able to toggle barriers on/off for a given solve and approximate it.
Maybe you could have a feature class of barriers with time ranges for the barriers. Be sure to use the calculate locations tool on it to make loading into a new analysis layer fast. For a give solve request, with a specific start time, you could load locations on the barriers class using a query to make sure you only include those barriers that apply for the start time.
Restrictions
You could have sets of restrictions appropriate for certain times of day, that you can turn on and off. But, as you mentioned, you would have to rebuild your network each time.
I had thought that you could use a script evaluator (python or vb script), and have the evaluator do some extra work to figure out if a given element is restricted or not, based on the time it is traversed. But it appears that script evaluators do not have access to AttributeValueAtTime. Also, script evaluators can be slow, and they depend on information built into the network.
By the way, this is very interesting! I love seeing this kind of creative usage of the software.
Thanks for the suggestions!
Did you just say that you can use the time an element is traversed in a 'normal' script evaluator? If so, how?
As you're interested in the use-case:
We are setting up a "visualisation and information tool for 'RIS' (River information services)". One part of the system (that I'm setting up) is a route calculation module for skippers that takes into account all kinds of restrictions on the fairways. I already used the custom evaluator with time schedules sample to make some custom evaluators for the operation times of locks and operated bridges (Thanks for that!), set restrictions for the dimensions of the vessels, speed limits, turning basins, etc. Thats all working fine.
Now I want to take into account the NtS (http://www.ris.eu/expert_groups/nts ) messages. That's some kind of traffic information for waterways. These messages may say for instance that a fairway is blocked by dredging on Mondays between 8am and 10am. These messages can be located by RIS codes that link to about 14000 point locations (our current working area). At the moment we see about 150-200 messages a week for our working area. They can be added, deleted or edited at any time.
At the moment I'm thinking to add a separate layer to the network dataset for those NtS messages and add a time-aware restriction evaluator to it. This means a network rebuild will be needed when the NtS messages are updated, or, we might update them with a certain frequency.
Patrick Stevens: If you have some time, could you look at another question I have? Show ETA from locations on the network when calculating route
Mody Buchbinder: sorry to hijack your thread!
I assumed that the script evaluators would have access to time. It doesn't look like that is case. I see AttributeValueByName is available, but AttributeValueAtTime is not. I'll go back and edit that post, so no one gets misled. Thanks for catching that!
Very interesting use-case. It seems like the custom evaluator could handle it, especially if you cache the 14000 restrictions in memory during Initialize, and also during Refresh when you notice that an update has occurred. Melinda Morang's GTFS evaluator does similar work and can handle much more than 14k in-memory restriction times. But if that doesn't work, rebuilding the network would be inconvenient but not impossible. 150-200 rebuilds a week on a regional network (as-in, not a nation full of streets), seems doable.
As to your request to check out another post on the forum, I'm not sure how to set up directions to work for you, so I sent a note to a co-worker who might be able to better answer your question. Hope you get your answer soon.
The barriers in Network Analyst are designed in a way that does not support time window now. Time window is only supported by Stops I believe.
I think you may need to evaluate the cost of the affected segment to evaluate it's own cost based on an input which is time started or something. Let me know if you need more elaboration...
Raymond