-
Notifications
You must be signed in to change notification settings - Fork 0
home
El caso de uso 10 está dedicado a la información relativa a eventos deportivos.
La DGT, con el servicio de balizamiento perimetral de eventos deportivos, recopila y publica la información de la localización en tiempo real de todos los eventos deportivos (competiciones ciclistas, eventos de atletismo en carretera, rallies, etc) que afectan a la circulación y seguridad vial de los usuarios que transitan por las vías del territorio español. La creación, publicación y eliminación de los planes y los recorridos de dichos eventos se realizará a través de los sistemas de la DGT.
Se utilizarán balizas V-2 para realizar el seguimiento de los eventos y conos conectados que informarán de los distintos cortes de las carreteras en las inmediaciones del circuito para garantizar la seguridad. De esta forma el usuario planifica mejor sus desplazamientos, y considerar la opción del uso del transporte público que permite reducción de las emisiones contaminantes.
La información de balizamiento de los eventos deportivos que llega al usuario final dependerá de la implementación realizada por el agente/tercero que consume la información de la plataforma DGT 3.0 y la publica a través del sistema de información del vehículo, aplicación móvil u otros dispositivos.
La plataforma cuenta con dos funcionalidades diferenciadas para la publicación (envío) y para la suscripción (recepción) de información. La primera es a través de una API REST del caso de uso y la segunda a través de un servicio MQTT en tiempo real.
La funcionalidad de publicación requiere de certificados de acceso que deben ser solicitados y suministrados por DGT 3.0. Estos certificados, de no haber sido solicitados ya, se deberán solicitar a soporte@cmobility30.es.
A continuación se muestran las URLs con las que se accede a cada funcionalidad:
| Modo | URL | Descripción |
|---|---|---|
| Publicación | https://pre.cmobility30.es/use-case-10 | Endpoint del entorno de integración de clientes para la publicación (ciertos métodos de publicación serán accesibles para el consumo) |
| Suscripción | ssl://production.cmobility30.es:8883 | Endpoint para la suscripción |
Este caso de uso dispone de una API REST para la publicación (envío) de los datos por parte de las empresas que así lo deseen. En los siguientes apartados se pueden encontrar los detalles de esta:
- Los detalles generales para realizar una petición:
- Información relativa a los métodos específicos del caso de uso:
- Información relativa al detalles de las tablas maestras:
Este caso de uso también dispone de un servicio de suscripción (recepción) de datos por parte de las empresas que así lo deseen mediante el protocolo MQTT. Este caso de uso es solo para recibir el seguimiento de los conos y las balizas v2.
A continuación se pueden encontrar los detalles de la suscripción MQTT para este caso de uso 10 (Eventos deportivos):
MQTT (MQ Telemetry Transport) es un protocolo de mensajería que se usa como un método simple y liviano para transferir datos hacia/desde dispositivos de baja potencia.
El protocolo admite un único patrón de mensajería, cada mensaje es publicado en un tópico al que se debe suscribir para recibir la información. Existen dos tópicos diferentes, para representar la información de conos y señales v2.
La suscripción al servicio de este caso de uso deberá ser mediante los tópicos:
out_usecase10_cones
out_usecase10_v2
En los tópicos se publican los eventos en formato JSON. Aquí se puede ver un ejemplo para cada tópico:
out_usecase10_cones:
{
"actionId":"f58ed72f41c9f3e10dd34e62afb7bf2a92b313e1bb2f74e367de80092c854a7c",
"timestamp":"2024-09-03T10:02:01.203Z",
"lon":-3.68563,
"lat":40.24298,
"eventTypeId":2
}out_usecase10_v2:
{
"actionId":"bb0bf84312ed13e30591279a6e0bc8e3ea46901161703dd2f045868e0bc71904",
"beaconTypeId":1,
"lon":-7.009654361999935,
"lat":38.52736428400004,
"timestamp":"2024-09-03T10:25:26.932Z",
"speed":50.0
}Descripción de los campos para el caso de uso de eventos deportivos a través de la plataforma DGT 3.0.
- actionId (texto): Identificador único del evento.
- beaconTypeId (número entero): Tipo de baliza.
- lon (número decimal): longitud de coordenadas de tipo WGS 84 donde se ha generado el evento.
- lat (número decimal): latitud de coordenadas de tipo WGS 84 donde se ha generado el evento.
- timestamp (Fecha UTC): Fecha y hora en formato UTC del momento en el que el evento se ha generado. Es necesario que sea de un máximo de 30 segundos de antigüedad con respecto a la hora UTC.
- speed (número decimal): Velocidad a la que se mueve el dispositivo v2.
Ver más información y un ejemplo de conexión aquí.
Todas las respuestas HTTP que no sean 200 – OK, se pueden considerar inválidas. No obstante, determinados métodos de la API pueden responder con código 202 - ACCEPTED junto con una descripción indicando el motivo de aceptación. Independientemente de si el código del mensaje es 202 o uno de error, el formato de la respuesta es como el siguiente ejemplo:
{
"status": 401,
"code": 1,
"message": "User not found or valid"
}-
HTTP Status: 202 - Accepted
Code Message 27 One more Beacon is expected in order to do the dynamic tracking
La información relativa a los errores en este caso de uso se puede encontrar aquí. Estos errores tendrán tres categorías principales:
-
HTTP Status: 401 - Unauthorized
Code Message 1 User not found or valid
-
HTTP Status: 400 - Bad Request
Code Message 0 Authenticate 2 Entity ID not found 3 Missing required property 4 The entity received cannot be processed 5 Incorrect token received 6 Expired token received 7 There is an error with the token provided. Please request a new one 8 No token received 9 Required request body is missing 10 Event is marked as expired by timestamp 11 Missing request header 12 Access denied role 13 Unique key violated 14 There is an error in one or more elements 15 Invalid GeoJson 16 GeoJson does not belong to municipality 17 TimestampStart should be future 18 TimestampEnd should be future 19 TimestampStart should be before TimestampEnd 20 The type is not a cone 21 Cone use type has to be Infrastructure 22 Cone vehicle type has to be None 23 The beacon type must have value 4 (Unique) 24 The plan requested to track was not found 25 The event requested to track has not started yet or has already finished 26 The provided coordinates for both dynamic tracking beacons are exactly the same
En el caso de obtener un error 3 - Missing required property la respuesta obtenida tendrá un valor en el message que nos indicará los campos que faltan por enviar:
{
"status": 400,
"code": 3,
"message": "[cityIne: must not be null, parkingId: must not be null, timestamp: must not be null]"
}-
HTTP Status: 500 - Internal Server Error
Code Message 28 Internal error