Skip to content
DGT 3.0 edited this page Nov 14, 2024 · 34 revisions

El caso de uso 13 está dedicado a la información relativa a la protección en tiempo real de ciclistas que circulan por la red de carreteras.

Dentro de la plataforma DGT 3.0 se implementa:

  • Una interfaz que permite el envío por parte de los suministradores de la información en tiempo real de sus usuarios que se encuentran montando en bicicleta por carreteras nacionales
  • Publicación de la información validada para que cualquier tercero autorizado por DGT pueda consumir la ubicación en tiempo real de los ciclistas para informar a los usuarios de sus aplicaciones / vehículos
  • La implementación de una lógica de validación de la información recibida para evitar problemas derivados de la inexactitud del GPS de los dispositivos a la hora de enviar su posición y recepción incorrecta de los datos

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 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-13 Endpoint del entorno de integración de clientes para la publicación
Suscripción ssl://production.cmobility30.es:8883 Endpoint para la suscripción

A continuación se describen las dos funcionalidades.

Publicació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:

General · (cmobility30.es)

  • Los detalles de las tablas maestras y datos que pueden componer el evento:

Tablas Maestras

  • Información relativa al evento que se debe enviar:

Evento

Suscripción

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. A continuación se pueden encontrar los detalles de esta:

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.

La suscripción al servicio de este caso de uso deberá ser mediante el tópico:

out_usecase13_cyclists

En el tópico se publican los eventos en formato JSON. Aquí se puede ver un ejemplo:

{
    "actionId": "f6df58ea71de392c9e783d8b1a4a94f34a3403sdcf1dff660fe31ae7e6beaa1e",
    "timestamp": "2021-03-15T13:34:00.000Z",
    "lonStart": -3.45368,
    "latStart": -4.45368,
    "lonEnd": 40.36586,
    "latEnd": 41.36586,
    "eventTypeId": 2,
}

Descripción de los campos para el caso de uso de ciclistas a través de la plataforma DGT 3.0.

  • actionId (texto): Identificador único del 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 15 segundos de antigüedad con respecto a la hora UTC. La fecha debe finalizar con el caracter 'Z' que marca que está en UTC
  • lonStart (número decimal): longitud de coordenadas de tipo WGS 84 donde se ha generado el evento
  • latStart (número decimal): latitud de coordenadas de tipo WGS 84 donde se ha generado el evento
  • lonEnd (número decimal): longitud de coordenadas de tipo WGS 84 donde finaliza el evento
  • latEnd (número decimal): latitud de coordenadas de tipo WGS 84 donde finaliza el evento
  • eventTypeId (número entero): identificador del tipo de evento

Ver más información y un ejemplo de conexión aquí.

Errores

Como se ha indicado anteriormente, todas las respuestas HTTP que no sean 200 – OK, se pueden considerar inválidas. El formato de la respuesta de error es como el siguiente ejemplo:

{
    "status": 401,
    "code": 1,
    "message": "User not found or valid"
}

*Esto no aplica para el Caso de Uso 9 - Grúas. La información relativa a los errores en ese caso se puede encontrar aquí.

Estos errores tendrán tres categorías principales:

Error de Autentificación

  • HTTP Status: 401 - Unauthorized
    Code Message
    1 User not found or valid

Error de Cliente

  • HTTP Status: 400 - Bad Request
    Code Message
    0 Authenticate
    2 Entity ID not found
    3 Missing required property
    4 The entity received cannot be proccessed
    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 Permission denied. Role assigned to user missing

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": "[deviceTypeId: must not be null, deviceUseTypeId: must not be null, informationQualityId: must not be null]"
}

Error de Servidor

  • HTTP Status: 500 - Internal Server Error
    Code Message
    13 Internal error

Home

Publicación

Suscripción

Clone this wiki locally