Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [sumo-dev] Netedit lane lengths and shapes
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.
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 <prikryl@xxxxxxxxxx>:
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
  prikryl@xxxxxxxxxx
_______________________________________________
sumo-dev mailing list
sumo-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://www.eclipse.org/mailman/listinfo/sumo-dev

Back to the top