|
Notes |
|
|
(0013682)
|
|
linla
|
|
12-01-2016 13:13
|
|
make it unnamed list will break the backward compatibility. alternatively, the unmodified version will only indicate the closing lanes, instead of indicating the complete road lane layout.
please verirify other data elements with the same type. |
|
|
|
|
I tested the difference, and the encoding with Objective Systems' asn.1 encoder has been exactly the same with named bitstring vs. plain bitstring. See the screenshots in the attached file.
Apparently, it is following rule 16.11 of X.691 even for named bitstrings. Is this a bug in the asn.1 tool, or is the above interpretation of these rule differences incorrect? Can you show a counterexample, where the encoding is really different? |
|
|
|
|
Dear Sebastian,
The value ‘0101’B is not a good example because the last bit is a ‘1’. Therefore, also a named list will encode the full value.
The value ‘10’B makes more sense. If I use the online tool from OSS Nokalva (http://asn1-playground.oss.com/ [^]), I get the following result:
You can see that the UPER encoding is 0x08 (00001000B: 4 bit length, 1 bit value, 3 bit padding). It is different though from the screenshot of Andras. I can check with Marben ASN.1 but it takes me some more time.
Best regards,
Laurens |
|
|
|
|
Dear Laurens,
Thank you for the good example! The ‘10’B encoding output is indeed different with the OSS and OBJ-SYS tools when using named bit string.
Let me check with OBJ-SYS to confirm whether they agree that this is indeed a bug in their implementation (or if they think that the OSS interpretation of the standard is wrong). I will come back on this issue, as I receive the answer from them. Then we can decide if/how to correct the LaneStatus data element.
Best regards,
Andras |
|
|
|
|
Dear all,
I received the confirmation from OBJ-SYS that their implementation has a bug, and the OSS implementation is correct. This OBJ-SYS bug will be fixed in the next revision.
So it is indeed the case that the presence/absence of named bits can make a difference with PER encoding. I think this is counterintuitive, but that's how it is.
Therefore I agree to the proposed resolution of the issue 7296, i.e. to remove named bits from the LaneStatus data element.
Best regards,
Andras |
|
|
|
|
please approve at ITSWG1#35 the change
from
DrivingLaneStatus ::= BIT STRING { outermostLaneClosed(1),
secondLaneFromOutsideClosed(2) } (SIZE (1..14))
to
DrivingLaneStatus ::= BIT STRING (SIZE (1..14)) |
|
|
|
|
|
This problem only effects variable size bit string types, and DrivingLaneStatus is the only one |
|
|
|
(0013933)
|
|
linla
|
|
12-04-2016 13:46
|
|
|
approved in ITS WG1#35 meeting. |
|
|
|
|
|
Implemented as: DrivingLaneStatus ::= BIT STRING (SIZE (1..15)) |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
(0014481)
|
|
linla
|
10-01-2017 15:19
(edited on: 10-01-2017 16:13) |
|
implemented in CDD V1.2.3 on Jan 2017
|
|
|
|
(0014504)
|
|
linla
|
|
18-01-2017 11:00
|
|
|
open again, to change the counting way and the hardshould status case |
|
|
|
(0014506)
|
|
linla
|
18-01-2017 11:09
(edited on: 20-01-2017 14:11) |
|
modifications implemented in V1.2.4 in WG1#38. counting from innerborder, and does not include hardshoulder status.
|
|
|
|
(0014547)
|
|
linla
|
05-04-2017 14:31
(edited on: 05-04-2017 14:33) |
|
email from Jasja Kapsch:
Hi Sebastian,
thank you for your answer. Some issues I see:
1. So you decided to “spoil” up to two bits in order to align the numbering. I am not against that, the only question is if it is the best solution. See next points.
2. What is missing in DrivingLaneStatus is that it “shall indicate the status of all drivable lanes on the carriageway”, and not just up to some lanes (e.g. up to last closed one, as with the current published CDD version). This is currently not excluded. So to really address the issue that trailing (i.e. open lanes) were previously not transmitted, we need to enforce the length of the DrivingLaneStatus BIT STRING to be equal to the number of drivable lanes on that particular road segment, not less and not more. In fact the receiving device derives the number of lanes present from the size of the BIT STRING, so the size need to be correct at all times.
3. Now if you decide to go for using bits 0 and 14 as padding, bit 0 shall always be included (that’s clear), but it is not clear when bit 14 is to be included. It can only be included if we have 13 drivable lanes. Otherwise we can’t include it. So what is the value of Bit 14 in LanePosition? Seems confusing to me. I do not want to imply that one need always to use the full length in order to use bit 14 (see previous point). Let’s get rid of Bit 14, and why not get rid of Bit 0 as well. After all the fact that Bit 0 is called “0” is human convention, and this is not send over the air. As the name says, the data element indicates the DrivingLaneStatus.
4. Where did the comment to count lanes from inside to outside come from? I have strong indications that Asfinag disagrees with this since lane counting in Datex II is from outside to inside.
ASN.1 representation DrivingLaneStatus ::= BIT STRING (SIZE (1..13))
Definition DE that indicates whether a driving lane is present and open to traffic.
A lane is counted from inside border of the road excluding the hardshoulder. The bit 0 is used to indicate the innermostLane, bit 1 is used to indicate the second lane from the inside border. The size of the bit string shall correspond to the number of drivable lanes of the carriageway.
Note: Hard shoulder status is not provided by this DE but in HardShoulderStatus as defined in A.29.
If a lane is present and closed to traffic, the corresponding bit shall be set to 1.
If a lane is present and open to traffic, the corresponding bit shall be set to 0.
The DE is used in ClosedLanes DF as defined in clause A.106.
|
|
|
|
|
Approved in WG1#39 with the following agreement:
1. For more than 13 lanes the DE shall not be transmitted. This will apply to the DF_LaneStatus.
2. The HardShoulder will not be included in the DrivingLaneStatus. |
|
|
|
|
|
Reopened @ITS1#42 and agreed to implement the ASN.1 representation of DrivingLaneStatus ::= BIT STRING (SIZE (1..13)) as suggested and agreed by Jasja. |
|
|
|
|
|
Decided to implement it in WG1#42. |
|
|
|
|
|
WG1#42: we also agree with the extended definition: The size of the bit string shall correspond to the number of drivable lanes of the carriageway. |
|