Hello Jan, Internal lane shapes are recomputed every time by default (although they can be fixed by setting an additional attribute). 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. 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.
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
