Closed WJSchakel closed 1 year ago
Stripe.Permeable
is removed, which declutters the cumbersome code. Stripes are now defined with a Stripe.Type
(which replaces StripeAnimation.TYPE
). The stripe type defines default permeability for all GTU types.
With a marker GTU type already no longer required (#27), and now also no permeability GTU type being required, code has really cleared up. The method animateNetwork()
is moved back to the constructor of OtsSimulationApplication
as no GTU types need to be provided (which the sub-classes did before).
To overrule default permeability of a stripe type, the method Stripe.addPermeability(GtuType, LateralDirectionality)
can be used. To overrule e.g. a solid line, add LEFT and/or RIGHT (both can be added). To overrule e.g. a block line, add LEFT or RIGHT to allow lane changes only in that direction, or NONE to prevent all lane changes.
In the LaneFactory
there is now a method addLanes(List, Stripe.Type...)
, which adds the input list relative to an existing similar method. From this list the stripes can be accessed after the call in which they are created. In this way users can add custom permeability to stripes.
The Stripe
class also includes an overrule type. This may be set by some scheduled event to simulate e.g. rush-hour lanes.
Drawing a line as dashed or continuous is based on the permeability given a provided GTU type. This is cumbersome as the type/permeability is already defined in various places (in XML, in
Stripe
(asPermeable
andLateralDirectionality
), and inStripeAnimation.TYPE
). To implement specific rules for specific GTU types (e.g. dedicated HOV lanes), the full complexity is required. But the logic of the drawn type is better suited at theStripe
, rather than being cumbersomely and incompletely derived from the permeability of a fairly random GTU type.