We 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?
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:
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, 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.
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?
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).
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.
Like you mentioned, though, 14,000 locations is quite a few and solve will take a performance hit.
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.
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.