El caso de uso 11 está dedicado a la información relativa a aparcamientos.

Este caso de uso pretende la recopilación y publicación de forma centralizada y homogénea la información en tiempo real relativa a aparcamientos en las ciudades españolas. Los agentes/terceros interesados pueden consumir la información mediante la suscripción. Permite en tiempo real por parte de los suministradores el envío de la información a la plataforma DGT 3.0 sobre la disponibilidad plazas de aparcamiento. Los consumidores podrán publicar la información en sus sistemas de información accesibles por el usuario final permitiendo a este planificar mejor sus desplazamientos y considerar el uso del transporte público.

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.

Tanto la funcionalidad de publicación como de suscripción requieren de certificados de acceso distintos 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:

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)

• Información relativa a los métodos específicos del caso de uso:

Metodos de publicación

Nota: Algunos métodos de publicación para la obtención de información también podrán ser utilizados por los consumidores .

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, el patrón Publicar-Suscribir: 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:

usecase11/free/{cityIne}

El parámetro cityIne es el identificador del municipio donde se genera el evento según el INE, hace referencia al municipio en la que sucede el evento por tanto cada municipio tendrá su propio tópico específico.

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

{
    "cityIne":50297,
    "parkingId":1,
    "free":14,
    "capacity":158,
    "timestamp":"2021-03-15T13:34:00.000Z"
}

• cityIne (número entero): identificador del municipio donde se genera el evento según el INE

• parkingId (número entero): identificador del aparcamiento

• free (número entero): número de plazas libres del aparcamiento

• capacity (número entero): capacidad total del aparcamiento

• timestamp (fecha UTC): fecha y hora en formato UTC del momento en el que el parking se ha actualizado por última vez. Es necesario que no sea un timestamp futuro con respecto a la hora UTC actual. La fecha debe finalizar con el caracter 'Z' que marca que está en UTC

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

Además los suscriptores también podrá acceder a los siguientes métodos de publicación de la API REST para la obtención de información:

• Información relativa a los métodos específicos de publicación accesibles:

Métodos de suscripción

Nota: La información que se está publicando en el entorno de desarrollo es una simulación con información no real que va cambiando a lo largo del día, de forma que se pueda probar la interface de consumo.

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 11 - Parkings. 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	Access denied role
  13	Unique key violated.In the INE code XXX, the first parkingId available is YYY
  14	There is an error in one or more elements
  15	Free capacity should not be greater than total capacity
  16	Invalid GeoJson
  17	GeoJson does not belong to municipality
  18	Timestamp can not be future
  19	Day of week not valid. Allowed values: 'L','M','X','J','V','S','D'
  20	TimeTable should not have duplicated days
  21	Inconsistent time range: startTime should be before endTime
  22	Inconsistent time range: there is a crossing schedule
  23	There was an error when creating the Datex II file
  24	There are no parkings in municipality or the provided INE code is not correct

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]"
}

Error de Servidor

• HTTP Status: 500 - Internal Server Error

  Code	Message
  25	Internal error