Dear Pieter,
look, the reason for not answering to dfrouter question is that we
simply only seldomly use it. I suppose I would be the one who should
be responsible for it as Eric and me originally wrote it and I was the
one who documented it.
What documentation about the dfrouter have you read? What is missing
in there? Mentioning that all sources/sinks must be supplied? Well, I
don't know why, maybe because dfrouter's behaviour is simply not
defined properly, but I don't like the documentation either.
And, well, if you like to, you are sincerely invited to extend the
documentation. You'd need to log-in and send us your username, then. I
think that is the procedure?
Regarding your question: yes, I think that's possible - or was, but
due to seldomly using it, there also was a lot of bugs in the code.
There must be an output which contains the detectors with their
computed types ("detector-output"?). If given back to dfrouter, these
types are not recomputed. Unless given an according option
("--revalidate-types"??).
Any help is appreciated.
I think there will be a publication about that tool soon. I think the
idea is quite fine, at least for the original area we have applied it
for (highway ring around the city of Cologne). You have detectors at
all exits and entries of the highway there. You still have the problem
that it's a ring, but as we were interested in vehicle flows, not
person routes, let's say, and at "in-between" detectors the vehicle
flows have been calibrated, and actually the probability to drive in
circle, once was very small, we neglected it.
Hope I could help.
Sincerely,
Daniel
2014-02-11 15:32 GMT+01:00 Pieter Loof <[email protected]>:
> 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
------------------------------------------------------------------------------
Managing the Performance of Cloud-Based Applications
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
Read the Whitepaper.
http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
_______________________________________________
sumo-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sumo-user
