Re: [sumo-user] Jaywalking

[Michael Behrisch <oss@xxxxxxxxxxx>]

Hi Yokhanan,
for the answers see below

Am 23.01.2018 um 19:07 schrieb Beck, Yokhanan Z.:
> 1) There does not seem to be a way to get the opposite sidewalk on a
> given street, if it exists. Currently I’ve just got a big lookup table I
> built myself, but I’d rather automate this. Most recently I’ve tried
> building a table at the beginning of the simulation by finding the edge
> which runs in the opposite direction for each road, and checking if they
> each have a “pedestrian” only lane. However, there seems to be no way to
> find the opposite direction road via TraCI! I can’t even find which
> junctions are connected via which edges, or which edges connect to which
> junctions. Am I missing something in the TraCI commands, or is there
> really no way to “traverse” the network graph via TraCI?

The concept of an opposite edge is not really well defined in every case
and it is not needed for the simulation that's why it is currently not
modelled. The only exception is when you want to model overtaking over
the opposite lane. If you do this you need to rebuild your network with
--opposites.guess which will annotate the leftmost lane of every edge
for which an opposite one could be found with a "neigh" element
mentioning the neighboring lane on the opposite side.

We try to limit TraCI to the dynamic parts of the simulation and access
the static parts such as the network graph via sumolib (which is
available for Python and Matlab at least). One reason is simply
technical (it is much harder to implement and maintain a TraCI function
than a simple XML parsing), the other is performance, the user should
not overload the script with TraCI calls which are unnecessary because
the values in question do not need a running simulation.

> 2) Likewise, there does not seem to be a way to get the end position of
> a pedestrian along its stage list – you can simply get the final edge.
> But as for where along that edge it is going, TraCI does not provide a
> way to access that. Is this correct, or is there something I’m missing?

This is correct, it is simply not implemented (there is no getArrivalPos
for the vehicle as well), I opened a ticket
https://github.com/DLR-TS/sumo/issues/3780

> 3) Also, when my new vClass=”pedestrian” pedestrians cross the road,
> they look like cars. Is there a way to adjust this so that they look
> like pedestrians and use their bounding box for collisions? Currently I
> create these new “pedestrians” in this way:

You can define the shape and the extensions of the "vehicle" when
defining the type, see
http://sumo.dlr.de/wiki/Definition_of_Vehicles,_Vehicle_Types,_and_Routes#Vehicle_Types
The easiest way is probably to define the type once (in XML) and then
use it in the call like traci.vehicle.addFull(vehID, routeID, typeID).

> 4) The answer to (1) above will likely also be helpful for this
> question. I want the pedestrians to “look both ways” before crossing the
> street – in other words, I want them to get access to all cars along the
> road they want to cross, within some certain distance, and decide
> whether to cross. I presume this means I will need to “traverse” the
> network like in (1). Is there another way of accomplishing this?

You could try context subscriptions which will give you every car in a
given range but you would still need to find out whether they are on the
road ahead, so probaly there is no other way than the one you mentioned.

> 5) The cars on the road seem to react to my new “pedestrians” as they
> cross the road by slowing down, changing lanes, and even stopping for
> them. However, these behaviors are only triggered by “pedestrians” who
> are immediately in front of them. They do not begin slowing down, for
> example, until the person is in their lane. However, “in real life” the
> car would usually see them walking toward their lane, and anticipate
> them entering it. One way I can handle this is by having the
> “pedestrians” keep track of the incoming cars (as in (4)), and then I
> can adjust those cars’ behaviors according to the geometry. Is there a
> better way of accomplishing this? In other words, is there a way for
> each vehicle to “look around” for other incoming “traffic” instead of
> just directly in front of themselves?

Theoretically your "vehicle" could indicate that it wants to change
lanes urgently and then the others would react. But currently this is
not accessible via TraCI and would also not work for the opposite edge.
In general SUMO's vehicles are poor in anticipation and usually only do
car following which is what you described.

Best regards,
Michael

PS: If you feel like implementing one of the missing features above, we
are happily accepting patches / pull requests :-)

Attachment: signature.asc
Description: OpenPGP digital signature