While I agree with the notion that XML is a stable foundation for sumo
inputs, I think there is some value in making infrastructure objects
available via sumolib. Possibly even via reading a .sumocfg as a shortcut
for reading network and additional objects from separate files.
I also don't think all the static stuff should be read over a socket
connection.

However, there is still the problem of sumolib portability when scripting
is done from languages other than python (there is no sumolib4java and
sumolib4matlab isn't kept up-to-date afaik).
Ideally, libsumo (and all traci clients) could be used to obtain a
sumolib-like network object for doing static queries.

regards,
Jakob




Am Fr., 2. Nov. 2018 um 15:06 Uhr schrieb Didac Busquets <
[email protected]>:

> 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
> [email protected]/ +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 <[email protected]> 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: [email protected] <[email protected]> On
> Behalf Of Michael Behrisch
> > Sent: 30 October 2018 08:30
> > To: [email protected]
> > 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:*[email protected] <[email protected]>
> >> *On Behalf Of *Jakob Erdmann
> >> *Sent:* 25 October 2018 21:28
> >> *To:* Sumo project User discussions <[email protected]>
> >> *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
> >> <[email protected] <mailto:[email protected]
> <[email protected]>>>:
> >>
> >>     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
> >>
> >>     Twitter
> >>     <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
> >>     [email protected] <mailto:[email protected]
> <[email protected]>> / +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
> >>     [email protected] <mailto:[email protected]
> <[email protected]>>
> >>     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
> >> [email protected]
> >> 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
> > [email protected]
> > 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
> [email protected]
> 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
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from 
this list, visit
https://www.eclipse.org/mailman/listinfo/sumo-user

Reply via email to