Dear Jacob,
maybe it's worth putting the discussion about Ticket 2072
from private mailing to the sumo-devel list.
We are currently facing three alternatives for
introducing 3d (x,y,z)-coordinates to the sumolib:
Alternative 0 - sumolib resemble the sumo.net.xml/netconvert behaviour
======================================================================
netconvert has the ability to eat z-coordinates during the
netbuilding process for z=0.
This is how SUMO/netconvert is, even though I find this annoying whenever
I come along this (often enough).
Here is an example, which is also part of yesterdays sumolib3d-unittest:
The node-file includes 3D-coordinates:
<node id="first" x="100.0" y="0.0" z="0.0" />
<node id="second" x="200.0" y="0.0" z="10.0" />
Once netconvert has finished it's work, the sumo.net.xml contains
for instance the following items:
<junction id="first" type="priority" x="100.00" y="0.00"
incLanes="the_other_way_0" intLanes=":first_0_0" shape="100.00,-0.05
100.00,-2.05 100.00,2.05 100.00,0.05">
<junction id="second" type="priority" x="200.00" y="0.00" z="10.00"
incLanes="this_way_0" intLanes=":second_0_0" shape="200.00,0.05,10.00 200.0\
0,2.05,10.00 200.00,-2.05,10.00 200.00,-0.05,10.00">
<lane id="this_way_0" index="0" speed="13.89" length="100.50"
width="2.00" shape="100.00,-1.05 200.00,-1.05,10.00"/>
As you can see here, the 'first' point is pure 3d with z=0 and
results in a pure 2d 'first' junction.
No so with 'second' as z is different from zero.
The lane 'this_way_0' is 2.5d since it starts its shape with a 2-tuple
and continues in full 3d.
I can fully understand that this helpful for backward compatibility ,
but it also introduces extra work, e.g. when processing sumo.net.xml files
in third application.
Fixing this issue in netconvert is not in my scope and probably also not
in the scope of the ticket :-) and maybe even a different discussion.
My conclusion about alternative 0:
I believe it's normal to expect the sumolib to behave like sumo/netconvert
itself, even though I don't like this behaviour.
Alternative 1 (dlr-team):
=========================
This is how I do understand your amendment to Ticket 2072:
any geometry functions should always return 3-tuple, regardless of the
dimensions of the net - also for 2d-nets.
Pro: This is great for all nets that contain 3d-Nodes.
Pro: This makes all users and developers of new script aware
that they might consider 3d-Networks as well
Con: This will break all existing scripts, once the user do
update to a new version of SUMO, since up to now
never 3-tuple were returned even on 3d-networks.
This will result in thousands of:
ValueError: too many values to unpack
This will also break all strips running on 2d-networks.
Even though it's perfectly fine to return 2-tuples on a
2d-Networks (Node only having x,y coords only).
My personal feeling is that most Networks are in 2d.
My conclusion about alternative 1:
This is a lot of avoidable trouble and extra work for your
users and coders, so please don't stick to it.
Alternative 2 (mixture):
=========================
Why not loading all nodes, and keep a record on the net-object
about its dimension.
As long as there are no 3d-nodes read by startElement()
the net remains as 2d net.
-> net has either only 2d nodes or all 3d-nodes are in xy-pane.
Once the first node with three coords is read, the net property
'dimension' is changed from 2 to 3.
After finishing reading all nodes from xml, the
nodes will be processed and missing z-coords will be filled with
z=0.
If the user accesses now geometry values she/he will be returned
either 2- or 3-tuple, depending on the net he is loading.
Rather then having a 2D-Wrapper (see below) i would suggest
a option 'with_z=True' returning optional the missing z=0 coord on a 2d net.
btw. in python3.5 this recipe would work:
x,y,z = net.getCorrds() if net.getDim() == 3 else *net.getCoords(), 0
A word about backward compatibility with 2D wrapper
================================================
I don't see the point in having a extra function getShape2D()
or getPositon2d() and so on.
As already in the ticket's amendment described, it's as easy
for a sumolib user to adapt the code
from:
x,y = getSomething()
to:
x,y,z = getSomething()
it is more straight forward - even if z as
variable is never used again
I would argument that adding a wrapper whatEverFunction2D()
to the whatEverFunction() might be of little effort, but still
in my opinion it will introduce dead code - But this is at your choice.
Geometries in TraCI
===================
B.t.w. Traci is more strict, it returns 2d coords even for 3d-nets.
So which way should we travel?
Best Marek Heinrich
simoserv GmbH
------------------------------------------------------------------------------
_______________________________________________
sumo-devel mailing list
sumo-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sumo-devel
