Dear Jakob, thank you for your quick reply.
On Fri, 18 Jan 2019, at 11:43 PM, Jakob Erdmann wrote: > Internal lane shapes are recomputed every time by default (although > they can be fixed by setting an additional attribute). Is it the "customShape" attribute? If so, and I specify the lane shape using "customStape", would that also mean that if I move the intersection a bit, or the starting/ending node of an outgoing/incoming edge, the position of the internal lanes would not move? > The reason for the re-computation is mainly historical, I supposed. > In typical input formats (e.g. OSM) internal shapes are not present > and must be computed anyway. That makes sense. > When customized, these internal lane shapes are also part of the plain- > xml (.con.xml) file.> See > http://sumo.dlr.de/wiki/Networks/PlainXML#Connection_Descriptions> When the > internal shapes are set in the proper way, they should not > change when editing some far-away intersection. I played a bit more with the original network and while I might have an example where moving an incoming endpoint of edge at a neighbouring intersection generates a network file with many internal lanes recomputed (the original network has an awful lot of short edges for no apparent reason, and also quite complicated system of pedestrian and bicycle crossings; it has, though, been generated via netconvert with just minimum complaints about sharp turns). I cannot reproduce it for a network that has been manually simplified and, at least from the perspective of the updated UI for netedit in 1.x, looks visually okay. So my guess is that it is a some kind of geometry issue, probably triggered by too small edge segments and too close placement of auxiliary intersections in the file. It seems to me that the only reasonable approach now would be to edit the network manually, hopefully only once, to clean it up, and to do all the editing of additionals afterwards... If you wish to have a look at the network file that in my experience triggers the recomputation, I can send it to you, together with some screenshots. Jan > > best regards, > Jakob > > > > Am Fr., 18. Jan. 2019 um 22:18 Uhr schrieb Jan Přikryl > <prik...@fd.cvut.cz>:>> Dear all, >> >> I have stumbled upon a very interesting effect when working with a >> certain network file in netedit:>> >> We have a moderately large SUMO network that originated as an export >> from a proprietary traffic management software used by our industrial >> partner. This network can be loaded into simulator, but cannot be >> edited in netedit (mainly due to the fact that it has walkways and >> bicycle lines over the middle stripe of a two-lane road that >> originate and end at the same intersection, netconvert+netedit do not >> like that). As I needed to do some edits, I have manually split those >> offending lanes by a small intersection so that netedit was able to >> read the network.>> >> Not surprisingly, when saving the edited network, all intersections >> were recomputed to different shapes, internal lanes were renumbered, >> and therefore positions of many detectors from the original model >> were now completely off (quite often behind the end of the lane) and >> signals were also differently indexed, but repeating the save >> generated a file with only minimal shape changes that I attributed to >> numerical errors.>> >> Today I realised that every time I load the network into netedit, >> do a minimal change in lane connections at some (auxiliary, >> unsignalised) intersection, and save the network back, all internal >> lanes seem to get recomputed again into different shapes, e.g. >> going from>> >> <lane id=":HEL704_28_0" index="0" speed="13.90" length="31.78" shape="- >> 4254.83,689.01 -4248.90,691.34 -4239.85,694.34 -4230.72,697.02 - >> 4224.51,698.40"/>>> >> to >> >> <lane id=":HEL704_28_0" index="0" speed="13.90" length="11.97" shape="- >> 4255.56,691.51 -4252.46,692.60 -4249.88,693.42 -4247.33,694.33 - >> 4244.35,695.68"/>>> >> so the new lane seems to be actually 20m shorter. This unfortunately >> again renders many of the manually updated detector positions in the >> network completely useless, as the detectors are again placed behind >> the end of the updated lanes.>> >> Some non-internal lanes do change as well, but many of them do not.>> >> I am not filing this as a bug as I have my doubts about the original >> network (i.e. the original did not went through the supported nodes-edges- >> connections combo, as I need information about the shape of internal >> lanes and that one is not present in the "plain XML" format; as a >> result the network may contain some really weird shapes, although >> netconvert only complains ).>> >> Is this the expected behaviour? If so, could someone elaborate a bit >> on why is it necessary to recompute the shapes in the whole network >> and not only the affected intersections (I am just curious)? Is there >> anything I can do to prevent that (even if it requires compiling from >> git, I have no problem with that as the only alternative is a manual >> edit of 500+ kB XML file).>> >> Thanks! >> >> -- >> Jan Přikryl >> prik...@fd.cvut.cz >> _______________________________________________ >> sumo-dev mailing list >> sumo-dev@eclipse.org >> To change your delivery options, retrieve your password, or >> unsubscribe from this list, visit>> >> https://www.eclipse.org/mailman/listinfo/sumo-dev > _________________________________________________ > sumo-dev mailing list > sumo-dev@eclipse.org > To change your delivery options, retrieve your password, or > unsubscribe from this list, visit> > https://www.eclipse.org/mailman/listinfo/sumo-dev -- Jan Přikryl prik...@fd.cvut.cz
_______________________________________________ sumo-dev mailing list sumo-dev@eclipse.org To change your delivery options, retrieve your password, or unsubscribe from this list, visit https://www.eclipse.org/mailman/listinfo/sumo-dev
