WG SXL Standardization 2024-06-18 #74
emiltin
announced in
Working Groups
Replies: 0 comments
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
Participants
Martin, David, Emil
Traffic Sensors
Are we interested in specialized features and data types, or would we rather converge on data types that are interoperable and easy to use, configure, integrate, etc?
How do we handle tenders, contracts, and software updates and maintenance?
Open hardware
We previsously discussed open hardware, i.e. a specification for how to build a sensor, based on standard equipment,, using open source OS and software. Sensors would be a simpler type of equipment in case we wanted to test this model.
But it would also place more responsibility on the authorities, to make sure the solution works and is updated. And it might require more competence, unless we can hire someone to manage such a project. EU-funding?
Data types
Simple, this is where we want to start:
Count
Speed
Classification
Occupancy (percentage)
Presence (on/off)
More complex:
Data types: Advanced classification: axels, bike helmets, kids/adults, type of car, truck length
Tech: 3D, lidar, point clouds
Servere analysis: OD matrix, travel times, number of steps, turn fractions, brake patterns....
A data types does not say anything about the technilogy used to collect data. It could a loop, a video, lidar.
Aggregation
This is handled by the core spec, ie. subscription update rate.
Classification
Different classifications exists in various countries. There is also EU standards? We probably need to support different schemas, and perhaps let supervisors choose which one to fetch data in.
Batching
The current TLC SXL has two sets of status message, one for getting data for a single detector logics, and one set for fetching for all detectors logics at the same time, which reduces overhead, since you send less messages.
Detector vs. detector logic
There is distinction between raw detector data vs. processed detector logic data
An example is a push button, which can just be on or off. A detector logic has some logic, based on input from one or more detectors. For example it could count how many times the button has been pushed.
This is similar to presence vs. count: presence is whether the button is pressed, count is how many times it was pressed.
There is a mapping between detector logics and detectors. It would be useful to have a way to fetch this mapping.
Streaming / Historic / Batching
For RMSP 4 we're considering concepts for streaming data.
Perhaps we can think of introducing some of this in RSMP3, eg. a "batch" flag when subscribing to data, so you get batch of detailed data once in a while.
This is part of core spec, not SXLs.
Beta Was this translation helpful? Give feedback.
All reactions