-
-
Notifications
You must be signed in to change notification settings - Fork 10
Description
Pitch
Following discussion in #504 and on Slack, we agreed on changes to the data model to introduce new table which will enable us to develop new features that are expected.
In this case, we decided to create a “poses” table (a table containing, for line, a related camera, an azimuth at which detection are made) i.e.: one line for a fixed camera and as many lines as there are positions for PTZ cameras.
Hence relation ships between camera detection and sequences tables will evolve
About the table poses
Below some guideline about the new table (Description is here for the purpose of the issue but not sure if we include it postgresSQL tables)
Do we include a created_at field ? -> To discuss
| Column | Type | Constraints | Description |
|---|---|---|---|
| id | INT | PRIMARY KEY | Unique identifier |
| camera_id | INT | FOREIGN KEY → cameras(id) | Reference to the related camera in cameras table |
| azimuth | FLOAT | CHECK (azimuth BETWEEN 0 AND 359/360) | Azimuth angle value |
| created_at | TIMESTAMP | DEFAULT CURRENT_TIMESTAMP | Record creation timestamp |
What has to be done
-
Add every thing related to the introduction of a the new table poses in the api
-
Update in tables:
- detections table :
- create fk pose_id (if possible to be empty for now, until migration)
- delete fk camera_id to pose_id -> in another PR with associated migration
- delete azimuth field (as if it was the one related to the current pose)
- sequences table :
- create fk pose_id (if possible to be empty for now, until migration)
- detele fk camera_id to pose_id- > in another PR with associated migration
- detections table :
-
API ressource CAMERAS :
- Update GET /api/v1/cameras/ -> Fetching all cameras gives a list of camera. For each element of the list, add a "field"
poseswhich list a list if azimuth, ex [{id_1: 358, id_3:45}], see full exemple at the en of the issue -> we can discuss about the exact format - Update GET /api/v1/cameras/{camera_id} -> For one specific camera, same logic as above
- Update POST /api/v1/cameras/ to include azimuth when registering a new cam -> To discuss ?
- Update GET /api/v1/cameras/ -> Fetching all cameras gives a list of camera. For each element of the list, add a "field"
-
API ressource POSES :
- Create POST : /api/v1/poses/ -> create a given pose for a given camera : requested body camera_id and azimuth
- Create PATCH : /api/v1/poses/ -> updates a given pose -> requested body pose_id and azimuth
-
Add migration script
-
Update UML at
scripts/dbdiagram.txt -
Do not forget to add/update tests :)
Thanks a lot !
Happy to discuss it !
closes #504
Exemple value for the updated : /api/v1/cameras/
[
{
"id": 0,
"organization_id": 0,
"name": "string",
"angle_of_view": 0,
"elevation": 0,
"lat": 0,
"lon": 0,
"is_trustable": true,
"last_active_at": "2025-11-14T14:43:28.136Z",
"last_image": "string",
"created_at": "2025-11-14T14:43:28.136Z",
"last_image_url": "string"
"poses": [{id_1: 358, id_3:45}]
}
]
Metadata
Metadata
Assignees
Labels
Type
Projects
Status