After diving into the relevant SUMO code I found out why DFRouter discards
many of my detectors. Apparently all detectors that have at least one road
leading to it that does not contain a detector, are marked as source
detectors. In a later part of the code all source detectors that have a
path leading to another source detector are marked as discarded. The way to
fix this is by adding the flag "strict-sources" which ensures that all
detectors with at least one detector in front of it become 'in between'
detectors and all detectors with no detectors in front of it become the
source detectors.

I, and others with me, would save time searching the code if there would be
an explanation given in the documentation for the flag "strict-sources",
since the current explanation is only "; default: false". This is actually
true for a few more flags of SUMO modules. In general, it would be nice to
have a few sentences per flag such that the implications of adding a flag
become more clear.

Greetings,
Pieter


On 11 February 2014 15:32, Pieter Loof <[email protected]> wrote:

> I wonder if anyone can react on my mail above/below that I sent a week
> ago. DFRouter discards most of my detectors (around 80%) and I don't know
> why. Almost all detectors are close to the boundaries of my network,
> although they are not always on edges that start or end at the boundary of
> the network. Should the edges be boundary edges in order to accept
> detectors that are placed on them?
>
> I made DFRouter produce a log file, which contains thousands of lines like
> these:
> - "Warning: Quitting checking for being a source for detector X due to
> seen edge limit."
> - "Warning: Quitting checking for being a false source for detector X due
> to seen edge limit."
>
> These messages are printed a lot of times per detector. I wonder what
> these messages mean. The position of the detectors on the edges does not
> really matter, since if I set all detectors at pos="1" then the number of
> discarded detectors and the number of warnings is the same as when I set
> the positions to computed position values.
>
> Alternatively, is there a way to provide the detector types as input to
> DFRouter?
>
> Greetings,
> Pieter
>
>
> On 4 February 2014 14:25, Pieter Loof <[email protected]> wrote:
>
>> Hi all,
>>
>> I have a program that generates a file with detector definitions and a
>> file with detector measurements based on real data. I have used these file
>> types as input before in a testing phase, it then worked correctly. But
>> now, when running DFRouter and generating a detector output file, I see
>> that the majority of detectors is being discarded, only a few became of
>> type source or sink. What problems can cause DFRouter to discard detectors?
>>
>> In my scenario. all detectors have non-zero flows most of the time
>> intevals, the max search depth option for DFRouter is also high enough so
>> that no unfinished route warning occur.
>>
>> Best regards,
>> Pieter
>>
>
>
------------------------------------------------------------------------------
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
_______________________________________________
sumo-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sumo-user

Reply via email to