I have been using the depreciated GTFS public transit tools for some analysis in ArcMap 10.8.1. I have been trying to model the impact transit agency fare boundaries have had on the generalized cost of transit trips which require transfers to other transit agencies' services. I have been trying to use point barriers to do this - I used the intersect tool to create a series of points (municipal boundary line shapefile intersected with the TransitLines shapefile outputted by the Add GTFS to a Network Dataset tool), and then loaded those points as point barriers with an added cost set to 50 minutes. My thoughts were that the TransitLines Transit Evaluator would cross these points and the added cost would impact the analysis.
I have set the service area analysis settings to measure a total travel time of 60 minutes - however my results with the point barriers loaded do not reflect any added cost or travel delay, and I find that they make no difference at all with or without them. Both the service area analysis and the point barrier added costs are set to the same Attr_TravelTime impedence field.
I am wondering: did I correctly utilize the point barrier feature? And do they impact the outputs of service area analyses' at all - and if there is a better way to achieve this sort of "delay/impacted travel time" feature I am trying to analyze for trips that cross a boundary.
Any help would be extremely welcome! Thank you everyone in advance.
There is no technical reason I can think of why an added cost point barrier on one of the TransitLines wouldn't work. Did you make sure to set the BarrierType field in Point Barriers to "Added Cost", or 2? If it's still set to 0, then it's functioning as a restriction barrier and ignoring the added cost.
That said, I think there is a larger, more fundamental problem with your approach of attempting to add a time cost to your analysis to model fares. The transit schedules are in a lookup table, and the transit evaluator queries this table for the time of day when the traveler arrives at the initial stop for that segment. The schedules are very specific and exact. Let's say the traveler departs on a bus at 8am along a particular segment where you have placed one of those point barriers. Normally the bus takes 10 minutes to reach the next stop, so when the solver queries the transit schedules to determine the cost to traverse the next segment along the transit line, it will be looking for trips that start at 8:10 along that segment, and it will see that the same bus that the traveler is already on does that, and the traveler will just zoom right through in a logical and realistic manner. But if your point barrier adds 50 minutes to the trip, the traveler now arrives at the next stop at 9:00 instead, and the schedules are queried for 9:00. The transit schedules could be completely different by that point, and the traveler might have to sit and wait for the next bus, or it might find that the most efficient path from A to B is now to walk or ride some other transit line. Modeling monetary cost as time in this situation just isn't going to work.
Here is a possible explanation of why you're not seeing a difference in your Service Area. Service Area just searches outward from the Facility to find all possible network segments that are reachable within the time limit, and then it creates a polygon around them. It's possible that all the network segments are reachable either without transit or using some alternative transit lines, so the time delay you put on the one segment didn't make any difference to the total segments reachable. If you have a really dense transit network, this could reasonably happen. Alternatively, if your transit is so infrequent and not timed to correspond to whatever your Service Area start time is, it's possible that the Service Area basically just reflects walking anyway, and the transit wasn't contributing anything in the first place.
You said you want to model some kind of "generalized cost", which I presume is some way of measuring the desirability of transit trips or an annoyance factor or something like that, which incorporates not only raw travel time but also fares and maybe some other less tangible costs. I think a better solution might be to create a separate cost attribute on the network to model monetary cost, and then accumulate this attribute while solving optimizing based on travel time. In the results, you can see the unchanged total travel time, but you can also check the accumulated value of the monetary cost according to how many of your point barriers it traversed. Possibly you could extrapolate beyond that to other, more complex cost attributes to accumulate, depending on your needs. I haven't fully thought through how that would work, but I think there are definitely possibilities here.
Finally, I presume you have some reason for using ArcMap and the deprecated tools, but you, and anyone reading this, are highly encouraged to migrate to ArcGIS Pro and the built-in tools for public transit analysis there.
Thanks for your speedy reply! Your pointer towards using a separate cost attribute is helpful - however I'm having some trouble in configuring a network dataset that can include them. I have pasted the intersected points shapefile (of TransitLines and the municipal boundary) into a feature dataset where I plan to make a new network dataset, however I am unable to add the feature to participate in the second step of the process.
Is there a reason I am unable to add the feature to participate in the network dataset? And is there perhaps a better way to incorporate the points features into the analysis (I am thinking of having a fare cost attribute with an evaluator using the points set at "junction" and with a constant of 50 to achieve an accumulation of that cost of 50 when passing the points). I will probably give the public transit tools in ArcGIS Pro a try too, I'm just more familiar with the ArcMap ones - thanks for your suggestion!
I presume by "the second step of the process" you mean in the Create Network Dataset wizard in ArcMap. Hmm, I'm not sure why a point feature class wouldn't show up as a valid option in there. Did it end up as a multipoint instead of a normal point, perhaps? Like a transit line had multiple intersections, and both points ended up in the same feature instead of unique features?
Oh! I wonder if that was what caused the strangeness with your barriers!