Error of PT EnumRoutes

Hello, everyone:

There is a error msg like that:

F(801): (EnumRoutes) Program error: Too many routes for an origin zone (addressing limit).

F(805): (EnumRoutes) The above error occurred while saving a route from 1937-1.

F(658): Error Return 2 from REnum.

Is there a routes limited in EnumRoutes?

And how to do about it.

Thanks

Parents
  • Hello.

    Your route enumeration spread and xfers settings seem to be generating too many routes in your model, which PT cannot handle in memory. This depends on the boundary conditions you set for the route enumeration process and the transit system itself.

    It is necessary to tighten the spread and xfers conditions in the route enumeration, to generate a smaller number of routes. Please notice that in a complex PT system there can be several combinations of routes for each OD, and PT generates and enumerates them on the basis of your factors and your conditions. We generally therefore suggest to start with very constrained processes, with low values of spread and controlled xfers and check connectivity and route enumeration/evaluation with those values. In my view, in many cases (but this depends on the system), for each user class (e.g., based on income level) the routes that are considered between an OD pair are very close to the best path, particularly considering the simplification of the PT system in a macro-level frequency-based model.

    Note that also boarding penalties are very important in discarding combinations with multiple xfers, and they are needed for constraining this process, since they reduce the number of xfers within an OD path, and should be used in the model consistently.

    The route enumeration parameters that can be used to constrain the route enumeration process are the below, note that the values used below are just examples, but the values to be actually used depend on the specific model and PT system:

    ; MINXOD = N. Transfers Min Cost Route; X = N. Transfers along an alternative route
    ; If MINXOD > AONMAXFERS --> No routes
    ; Else If MAXFERS < MINXOD <= AONMAXFERS --> Only AoN Best Cost route
    ; Else If MINXOD <= MAXFERS
    ; (generally assuming MAXFERS > EXTRAXFERS1 >= EXTRAXFERS2)
    ; If X <= MINXOD <= MAXFERS --> OK (EXTRAXFERS1 and EXTRAXFERS2 ignored)
    ; if X > MINXOD <= MAXFERS; X <= MINXOD+EXTRAXFERS2; X<=EXTRAXFERS1 ? OK
    ; 	-> Therefore cap given by Minimum(MINXOD+EXTRAXFERS2,EXTRAXFERS1,MAXFERS)
    
    AONMAXFERS  = 8   ; max number of transfer for min cost path (if greater than MAXFERS only the AON path is produced)
    MAXFERS     = 3   ; max number of transfers for all paths
    EXTRAXFERS1 = 1   ; max number of transfers allowed for routes other than minimum cost route
    EXTRAXFERS2 = 1   ; max number of transfers allowed above the transfers on the minimum cost route
    
    ; SPREADFUNC=1: SPREAD = MAX(GCost(MinRoute)* SPREADFACT, GCost(MinRoute) + SPREADCONST)
    ; SPREADFUNC=2: SPREAD = GCost(MinRoute)* SPREADFACT + SPREADCONST --> larger spread than SPREADFUNC=1 if SPREADCONST>0
    SPREADFUNC  = 1
    SPREADFACT  = 1.05  ; % spread over minimum cost path (assumption: higher for walk access and egress than PnR and KnR)
    SPREADCONST = 5     ; in minutes

  • Thanks Filippo, I will try it.

    But I'm afraid the choice sets is to limited if a set the parameters more strict:> 

  • When you reduce your spread/xfers conditions, you can then use REPORTI-J and TRACEI-J to check the routes that are enumerated and evaluated between the ODs (e.g. i=1937 and j=1), and refine the definition of your penalties and factors based on what you observe and your local knowledge. 

    The number of routes that PT enumerates can be very large, because they are based on the schematic representation of the system and numerical values of generalized travel time, and (depending on the system) it might be possible to obtain a large number of combinations that should not be part of the choice set. Therefore it is, in my view, important to set these parameters (e.g., boarding penalties, etc.) and conditions (spread, xfers) to constrain the process consistently with the overall level of simplification. 

    This will also reduce runtime, allowing to run more calibration and sensitivity tests as well.

Reply
  • When you reduce your spread/xfers conditions, you can then use REPORTI-J and TRACEI-J to check the routes that are enumerated and evaluated between the ODs (e.g. i=1937 and j=1), and refine the definition of your penalties and factors based on what you observe and your local knowledge. 

    The number of routes that PT enumerates can be very large, because they are based on the schematic representation of the system and numerical values of generalized travel time, and (depending on the system) it might be possible to obtain a large number of combinations that should not be part of the choice set. Therefore it is, in my view, important to set these parameters (e.g., boarding penalties, etc.) and conditions (spread, xfers) to constrain the process consistently with the overall level of simplification. 

    This will also reduce runtime, allowing to run more calibration and sensitivity tests as well.

Children
No Data