Distance computation and distance evolution when activity locations are on the same link

[lukknapen]

• Our FEATHERS model predicts zone based daily schedules.

• We disaggregate these to street addresses (and hence coordinates) by means of a database containing buildings and their functions (office, residential, school, shop, etc).

• In some cases, two consecutive activity locations are on the same (long) network link being e.g. a kilometer apart.

• The plans generated by MATSim it.0 do contain many 'zero' distances and travel times. From some code inspection we understand that in the first stage (it.0) only the start and end link (and 'nearest node' ?) are used to compute distances.

• In later iterations, the occurrence frequency of zero distance legs decreases but we could not find in the MATSim code where/how the new distances are computed.

• We then have the following questions:

  (1) Where in the code should we look for the distance computation ? (2) If we still have zero-distance trips in the iteration 200, does this mean that we use insufficient iterations ?

• frequency tables for zero-langth trips by mode are given below for a 10% population (of approx. 750k traveling people) in the Netherlands:

  -- result: for it.0

  -- 691 "bike",0.0

  -- 153577 "car",0.0

  -- 17834 "pt",0.0

  -- 1066 "walk",0.0

  --

  -- totalNumberOfTrips = 173168

  --

  -- here the 'mode' is the one inherited from FEATHERS

  -- result:for it.1

  -- 953 "bike",0.0

  -- 122254 "car",0.0

  -- 32623 "pt",0.0

  -- 1221 "walk",0.0

  --

  -- totalNumberOfTrips = 157051

  -- result:for it.200

  -- 3575 "bike",0.0

  -- 429 "car",0.0

  -- 60885 "pt",0.0

  -- 234 "walk",0.0

  --

  -- totalNumberOfTrips = 65123

thanks

[JWJoubert]

Morning @lukknapen. The routing algorithm, when I last checked and worked with it, (always) takes a starting link and an ending link as inputs and computes the route between the two links. As you indicated, coordinates are snapped to links. So, if these two activities are indeed snapped to the same link, then the distances will remain zero (no matter how many iterations are executed). How the links on the route are traversed is a different story, but that does not have any bearing here, on your issue.

The routing would typically happen - during the MATSim iterations - in the replanning/strategy stage when, for example, rerouting occurs. And rerouting frequently happens after activity times are adjusted, or mode choices are executed, etc.

In our populations, we also frequently use coordinates, but I have not encountered this that often. I foresee one (fairly) easy fix. One can adapt the current router (whichever one you currently use) to check if the starting and ending links are the same. If they are, then use a Euclidean distance between the two activities instead. Here it will depend on how/where you implemented the Coordindates: possible as a direct attribute to the Activity, or via the location of the ActivityFacility associated with the activity.

Could that help?

[JWJoubert]

Is your network not possible overly coarse? There seem to be many (car) trips completely dropped... if I read your data summary correctly (I am not sure what they end 0.0 means).

[lukknapen]

You are probably right. Inspection of the data and results shows that a network containing main roads only was used. A new run has been started and i will report results as soon as it completes (may take 2 days).

[lukknapen]

• Your diagnosis was correct: we used a network that was too coarse.
• A new MATSim simulation is now running. For it.0 and it.1 we now find the following results (for a population of 750k agents (which represents 10% of the people having at least one trip in the FEATHERS prediction).
• The 0.0 at the end of each line is the distance used for filtering like in following line:

  cat 0.plans.csv | cut -d ',' -f 10,13 | grep ',0.0$' | sort | uniq -c

  where the columns are defined as

  
  1:person_id
  2:gender 
  3:age    
  4:employed
  5:activ_type
  6:activ_link
  7:activ_x
  8:activ_y
  9:activ_end_time
  10:mode
  11:dep_time
  12:trav_time
  13:distance
  14:start_link
  15:end_link

- Iteration it.0:

-- 691 "bike",0.0

-- 14410 "car",0.0

-- 1817 "pt",0.0

-- 1066 "walk",0.0

-- totalNumberOfTrips = 17984

- Iteration it.1:

-- 959 "bike",0.0

-- 11794 "car",0.0

-- 3449 "pt",0.0

-- 1260 "walk",0.0

-- totalNumberOfTrips = 17462

- Conclusion: 2.3% of the trips have zero length. Many of the zero distance do occur on short (few 100[m] long) links. This is definitely caused by our dis-aggregation and we will examine this problem in depth. It **may** be correct but i need to verify.
- Last remark: we find zero distances only for the case where **startLink == endLink** . We still need to figure out what happens when the locations are on links that have a common node.
- We will close this issue since the original problem has been solved. Thanks for your help.

[kainagel]

A somewhat higher level comment from my side: MATSim spatial resolution is down to the link level, but not any better than that. So if you need higher spatial resolution, you need to make your links shorter, e.g. cut them into pieces.

One consequence of this is that there is no standardized approach to how matsim deals with aspects below that link level resolution. For example, cars are essentially parked near the downstream end of the link. However, if an agent walks/"bushwhacks" to that parking location, it is undefined if the walking distance is the orthogonal distance to the link, or the actual walking distance to the parking location.

We made some efforts to standardize these computations (by putting them into NetworkUtils, FacilitiesUtils, PopulationUtils etc. and then trying to use them uniformly across the code). However, I am fairly sure that this has not diffused through the whole project.

If we wanted to fix the underlying problem, we would need to find consistent standards for a variety of problems. For example:

• If we remove a vehicle towards the downstream end of the link, how can it be parked further upstream? Should we teleport it there (maybe)? If so, should the corresponding emissions be deducted, and later be added when the vehicle departs?
• How should distances be computed for the accessibility computations? There, these things actually cause important errors since it makes a difference if we assume that all oppurtunities are attached to the downstream end of a link rather than having them along the link.

[lukknapen]

• The distribution for the length of the links where we find zero-distance trips is given in the attached density and distribution. Our current network is sufficiently fine-grained for our current purposes. In over 90% of the cases the link length is below 500[m]. There are a few outliers (up to 3.6[km]) which have been deleted from histogram generation in R in order to produce decent graphs.

linksWithZeroLengthTrips_lengthSorted_distrib_empirCDF.pdf linksWithZeroLengthTrips_lengthSorted_distrib_PDF.pdf

• One point is still unclear to me (question just for curiosity) : we find zero-distance trips if an only if startLink == endLink. Still wondering what happens when startLink and endLink differ and have a common node. My interpretation is that in such case the length of at least one of the links constitutes the distance.
• Thanks for your valuable help.

[kainagel]

The specification (not sure if it is followed everywhere through the implementation) is:

• if you are doing two activities on the same link, we assume that you leave one activity, travel a length of 0 along the link, and then start the next activity. I am not sure what happens if that trip is encoded as "vehicle on network", i.e. if you enter the vehicle, have a departure, followed by an immediate arrival. Or if the vehicle is skipped. My intuition would be with the first (which is what happens along U.S. strip malls where you often can't walk from one parking lot to the next).
• if the activities are on different links you have to drive (or walk, or cycle, or ...), even if they are attached to the same node. So assume two links are incoming links to the same node (where the activities seem very close). In MATSim, you will have to depart, traverse the node, find the upstream link to the link that you need to go (or some other path), make a u-turn, travel back the destination link, and arrive towards its downstream end. You will actually see these "weird" U-turns in VIA.

[lukknapen]

thanks a lot

On Fri, Feb 23, 2024 at 5:31 PM kainagel @.***> wrote:

The specification (not sure if it is followed everywhere through the implementation) is:

• if you are doing two activities on the same link, we assume that you leave one activity, travel a length of 0 along the link, and then start the next activity. I am not sure what happens if that trip is encoded as "vehicle on network", i.e. if you enter the vehicle, have a departure, followed by an immediate arrival. Or if the vehicle is skipped. My intuition would be with the first (which is what happens along U.S. strip malls where you often can't walk from one parking lot to the next).
• if the activities are on different links you have to drive (or walk, or cycle, or ...), even if they are attached to the same node. So assume two links are incoming links to the same node (where the activities seem very close). In MATSim, you will have to depart, traverse the node, find the upstream link to the link that you need to go (or some other path), make a u-turn, travel back the destination link, and arrive towards its downstream end. You will actually see these "weird" U-turns in VIA.

— Reply to this email directly, view it on GitHub https://github.com/matsim-org/matsim-libs/issues/3116#issuecomment-1961636280, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAHKFB7CAAMH6HSWYVX6P23YVC76HAVCNFSM6AAAAABDPPAUGGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNRRGYZTMMRYGA . You are receiving this because you modified the open/close state.Message ID: @.***>