| Re: [sumo-user] TraCI vs. XML (was Re: Getting the vehicle type of a lanearea dectector in TraCI/libsumo) |
_______________________________________________Hi Michael,
I must admit I was not aware of the full functionality of sumolib (probably confused by the other library called libsumo!).
I guess that sumolib will let me get traffic lights controllers and any info dubbed in the network XML - will check it in the next few days.
If so, then in the discussion sumolib vs TraCI for static network information I would definitely be with you (in favour of sumolib).
Regarding XML, I agree that it's a good standard. In any case, if there were any change (whether in the XML structure of networks or the actual language), as long as sumolib is updated (therefore acting as an interface), I'd be happy.
Regards,
Didac
-------------------------------------------------
Didac Busquets / Co-Founder and Chief Scientist
didac.busquets@xxxxxxxxxx/ +44 (0) 7919 076 981
Immense Simulations Limited
Studio J2, Witan Studios, 279 Witan Gate, Central Milton Keynes, MK9 1EJ
w3w: ourselves.depend.backpack
www.immense.ai
This e-mail including any attachments is intended for the addressee only. It is private, confidential and may be covered by legal professional privilege. If you have received this message in error please notify us immediately and remove it from your system. Immense Simulations Limited is a Company registered in England and Wales No. 09782647. Registered offices: International House, 24 Holborn Viaduct, City Of London, London, England, EC1A 2BN.
On 31 Oct 2018 16:40, Michael Behrisch <oss@xxxxxxxxxxx> wrote:
Hi Didac,
maybe your remark is a good starting point to discuss this a little bit
further and I would be happy if others could join.
My approach to sumo's interface has always been: XML first. So I would
rather ditch the current TraCI than move away from XML. The main reason
is that XML is a well known standard format with lots of parser
implementations out there, relatively easy to maintain and to extend.
TraCI on the other hand is a self-made binary protocol, severely limited
by some design choices which currently only allow a limited number
domains (at most 32) to work in and also at most 255 variables to ask
for. Of course there are workarounds but it is often not easy to
implement a new function and debugging is a pain. So if you ask me, I
would consider XML the stable part to rely on and TraCI the volatile
one. I understand that a lot of people need TraCI (and they can be sure
it will be there for a while) and they want to write code for one
interface only. But I also think it is worthwhile to make them aware of
facts like the one that traci.edge.getLaneNumber is not a cheap call and
that reading the network in advance with sumolib gives you a much nicer
object oriented (complete in memory) representation to work on.
Please tell me your thoughts.
Best regards,
Michael
Am 31.10.18 um 09:45 schrieb Didac Busquets:
> Hi Michael,
>
> I would disagree. I think it would be really useful to have a TraCI/libsumo module where you can query all the static info of the network (nodes, edges, lanes, links, detectors, traffic lights...).
>
> That would decouple our scripts from the file based representation of the network. What if the XML schema chanes? What if at some point you change XML by something else (e.g. JSON, reading from a database...)? Then any parsing script would be broken.
>
> I guess it's not a priority, but something to have in mind.
>
> Regards,
>
> Didac
>
> -----Original Message-----
> From: sumo-user-bounces@xxxxxxxxxxx <sumo-user-bounces@xxxxxxxxxxx> On Behalf Of Michael Behrisch
> Sent: 30 October 2018 08:30
> To: sumo-user@xxxxxxxxxxx
> Subject: Re: [sumo-user] Getting the vehicle type of a lanearea dectector in TraCI/libsumo
>
> Hi,
> another easy way would be to parse the input file defining the detector yourself. I am a little bit hesitant to add traci interfaces to all the static information available.
>
> Best regards,
> Michael
>
> Am 26.10.18 um 16:41 schrieb Didac Busquets:
>> Thank you Jakob,
>>
>>
>>
>> That is what I was doing right now, using the detector id as
>> XXXX_Type1 and then manually splitting it. But obviously is not very
>> clean nor portable.
>>
>>
>>
>> Would be great if in the future libsumo/TraCI offer a
>> getVehicleTypes() method.
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Didac
>>
>>
>>
>> *From:*sumo-user-bounces@xxxxxxxxxxx <sumo-user-bounces@xxxxxxxxxxx>
>> *On Behalf Of *Jakob Erdmann
>> *Sent:* 25 October 2018 21:28
>> *To:* Sumo project User discussions <sumo-user@xxxxxxxxxxx>
>> *Subject:* Re: [sumo-user] Getting the vehicle type of a lanearea
>> dectector in TraCI/libsumo
>>
>>
>>
>> Hello,
>>
>> there is currently no way to achieve this in a general way. A
>> workaround could be to encode this information within the id of the detector.
>>
>> regards,
>>
>> Jakob
>>
>>
>>
>> Am Do., 25. Okt. 2018 um 13:00 Uhr schrieb Didac Busquets
>> <didac.busquets@xxxxxxxxxx <mailto:didac.busquets@xxxxxxxxxx>>:
>>
>> Hi,
>>
>>
>>
>> I’m using TraCi and libsumo to read the values of lanearea
>> detectors. How can I query what vehicle type they detect? That is,
>> the value of “vTypes” in the definition of laneAreaDetector in the
>> additionals file.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Didac
>>
>>
>>
>> Immense Simulations Limited <https://htmlsig.com/t/000001D1FAJA>
>>
>> https://s3.amazonaws.com/htmlsig-assets/spacer.gif
>>
>> <https://htmlsig.com/t/000001DMCGQH>https://s3.amazonaws.com/htmlsig-assets/spacer.gifFacebook
>> <https://htmlsig.com/t/000001DRXRE6>https://s3.amazonaws.com/htmlsig-assets/spacer.gifLinkedIn
>>
>> <https://htmlsig.com/t/000001CVTDTW>https://s3.amazonaws.com/htmlsig-a
>> ssets/spacer.gif
>>
>> https://s3.amazonaws.com/htmlsig-assets/spacer.gif
>>
>>
>>
>> https://s3.amazonaws.com/htmlsig-assets/spacer.gif
>>
>>
>>
>> https://s3.amazonaws.com/htmlsig-assets/spacer.gif
>>
>>
>>
>> *Didac Busquets*/ Co-Founder and Chief Scientist
>> didac.busquets@xxxxxxxxxx <mailto:didac.busquets@xxxxxxxxxx> / +44
>> (0) 7919 076 981
>>
>> https://s3.amazonaws.com/htmlsig-assets/spacer.gif
>>
>> *Immense Simulations Limited*
>> Studio J2, Witan Studios, 279 Witan Gate, Central Milton Keynes, MK9
>> 1EJ
>> *w3w*: ourselves.depend.backpack
>> www.immense.ai <https://www.immense.ai/>
>>
>> https://s3.amazonaws.com/htmlsig-assets/spacer.gif
>>
>> https://s3.amazonaws.com/htmlsig-assets/spacer.gif
>>
>> This e-mail including any attachments is intended for the addressee
>> only. It is private, confidential and may be covered by legal
>> professional privilege. If you have received this message in error
>> please notify us immediately and remove it from your system. Immense
>> Simulations Limited is a Company registered in England and Wales No.
>> 09782647. Registered offices: International House, 24 Holborn
>> Viaduct, City Of London, London, England, EC1A 2BN.
>>
>>
>>
>> _______________________________________________
>> sumo-user mailing list
>> sumo-user@xxxxxxxxxxx <mailto:sumo-user@xxxxxxxxxxx>
>> To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/sumo-user
>>
>>
>> _______________________________________________
>> sumo-user mailing list
>> sumo-user@xxxxxxxxxxx
>> To change your delivery options, retrieve your password, or
>> unsubscribe from this list, visit
>> https://www.eclipse.org/mailman/listinfo/sumo-user
>>
>
>
> _______________________________________________
> sumo-user mailing list
> sumo-user@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/sumo-user
>
sumo-user mailing list
sumo-user@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/sumo-user