-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
schema/cam update schema according to CAM ETSI TS 103 900 V2.1.1 #248
schema/cam update schema according to CAM ETSI TS 103 900 V2.1.1 #248
Conversation
Signed-off-by: Hugues Oudeville <hugues.oudeville@orange.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please split the big commit into a set of more digestible commits, for example:
- 1 commit to fix the existing schema without adding anything new
- 1 commit adding the RSU container
- 1 commit adding the special_vehicle_container with (e.g.) just public_transport_container
- 1 commit for each of the other special_vehicle_container alternatives...
50dbcf7
to
4a945c7
Compare
Thanks for the quick respin! :-) I'll look into it tomorrow morning... In the meantime, a few comments about the commit log titles (cf process documentation being reviewd internally):
|
c343c38
to
480ab1e
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If you agree with the proposal by @mathieu1fb:
- objects that have a
_value
and a_confidence
properties, and when both those properties have anunavalaible
value, then:- that object is not
required
- the
_value
property for that object is required - the
_confidence
property for that object is not required - do not add any
$comment
(but keep existing ones to avoid churn) - also, it's JSON, so ordering of keys in objects does not matter; where possible, I think the confidence property of an object should be after all the other properties
- For example, the
altitude
object inreference_position
:"reference_position": { "type": "object", "required": [ "latitude", "longitude" ], "latitude": {...}, "longitude": {...}, "altitude": { "type": "object", "required": [ "altitude_value" ], "altitude_value": { "type": "integer", "description": "...", "default": 800001, "minimum": -100000, "maximum": 800001 }, "altitude_confidence": { "type": "integer", "description": "...", "default": 15, "minimum": 0, "maximum": 15 } }, "position_confidence_elipse": {...} }
- that object is not
Okay. I agree. I am going to update according to this proposal But @ymorin-orange, @mathieu1fb just to get sure before starting :
|
IMHO, I would say it should also apply to any property that has an
Then drop the comments in the objects/properties you move around or otherwise fix. And you did add at least one, in |
I'd say OK, unless it turns out absolutely every field is optional and we cannot make sense of the message that would be sent (let's say a CAM without latitude and longitude...). Unless it allows to send lighter CAMs with only what has changed compared to the previous one! |
Yes, there are fields that are really mandatory! Latitude and longitude are, for sure!
Unlike DENM, I don't think there is a sequence number in a CAM, so we would not know which previous one to update (but a given object may only have a single position anyway. Let's not make that too complex either!)... |
You are right. My bad. |
480ab1e
to
5152103
Compare
Signed-off-by: Hugues Oudeville <hugues.oudeville@orange.com>
Signed-off-by: Hugues Oudeville <hugues.oudeville@orange.com>
Signed-off-by: Hugues Oudeville <hugues.oudeville@orange.com>
5152103
to
93628fc
Compare
schema/cam/cam_schema_2-1-0.json
Outdated
}, | ||
"cen_dsrc_tolling_zone": { | ||
"type": "object", | ||
"description": "information about a the position of a CEN DRSC Tolling Station operating in the 5,8 GHz frequency band.", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Typo: s/DRSC/DSRC/ (ref)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Except for the minor typo, it all seems good to me, now. When you fix that typo and re-push, just merge without requesting another review.
Ok, typo fixed, and thank you for the review. |
Signed-off-by: Hugues Oudeville <hugues.oudeville@orange.com>
Signed-off-by: Hugues Oudeville <hugues.oudeville@orange.com>
In CAM TS 103 900 v2.1.1, the high frequency container can be either a basic vehicle high frequency container or a RSU high frequency container Signed-off-by: Hugues Oudeville <hugues.oudeville@orange.com>
Signed-off-by: Hugues Oudeville <hugues.oudeville@orange.com>
Signed-off-by: Hugues Oudeville <hugues.oudeville@orange.com>
Signed-off-by: Hugues Oudeville <hugues.oudeville@orange.com>
Signed-off-by: Hugues Oudeville <hugues.oudeville@orange.com>
Signed-off-by: Hugues Oudeville <hugues.oudeville@orange.com>
Signed-off-by: Hugues Oudeville <hugues.oudeville@orange.com>
Signed-off-by: Hugues Oudeville <hugues.oudeville@orange.com>
Signed-off-by: Hugues Oudeville <hugues.oudeville@orange.com>
93628fc
to
d01d821
Compare
Features:
Closes: #217
How to test:
Check the workflow job for CAM schema 2.1.0
Compare the 2.1.0 schema to the CAM ETSI TS 103 900 V2.1.1 (https://forge.etsi.org/rep/ITS/asn1/cam_ts103900/-/tree/V2.1.1)
Expected results:
The job succeeds (no validation error occcurs)
The 2.1.0 CAM schema should correspond to the Technical Specification