Introducción

En este workshop vamos a realizar un sencillo ejemplo con la plataforma que cubrirá los siguientes puntos:

Modelado de dos ontologías: Modelaremos las ontologías de este caso practico, una utilizando como base un Datamodel GSMA y otra creando la estructura de datos desde cero.
Ingesta desde un portal Open Data, utilizando el Flow Engine: Definiremos dos flujos de información que recuperarán información desde el Open Data de la ciudad de Barcelona y almacenarán dicha información en las ontologías definidas anteriormente.
Creación de un visor GIS: Una de las ontologías previamente modeladas almacena información georeferenciada. Definiremos un visor GIS en plataforma para mostrar dicha información sobre un mapa.
Creación de un Dashboard: Realizaremos un sencillo Dashboard, que estructurará visualmente la información almacenada en la plataforma proveniente del portal Open Data.
Exposición en un API REST: Utilizaremos el API Manager para exponer una operación con la información de una de las ontologías.

El ejemplo consistirá en una carga de datos desde el portal Open Data de la ciudad de Barcelona. En concreto se elegirán dos recursos del dataset del servicio de alquiler de bicicletas. Estos recursos son: El inventario de estaciones de alquiler y el estado de cada estación que se refresca periódicamente.
Dentro del diagrama de componentes de la plataforma, en la siguiente imagen podemos ver rodeados los componentes con los que vamos a trabajar:

Control Panel: Es la interfaz web con la que actuaremos para trabajar con la plataforma
Flow Engine: Motor de flujos que hará la ingesta de los datos desde el servicio Open Data del ayuntamiento de Barcelona. En el ejemplo, se definirán dos flujos: uno para consultar y crear el inventario de estaciones en la plataforma y otro para consultar y actualizar periódicamente el estado de las estaciones.
Semantic Broker: Proporciona el punto de entrada de la información en la plataforma. Verifica los permisos de acceso a la información y que esta es correcta, de acuerdo con el esquema definido en la ontología y si es así la pasa al módulo de almacenamiento. En nuestro caso, el Semantic Broker proporciona al Flow Engine de forma transparente, el punto donde tiene que volcar la información consultada en el portal Open Data, y se encarga de validarla con el esquema definido en las ontologías.
Semantic Datahub: Proporciona la infraestrucutura física (Bases de datos) para el almacenamiento de la información, su consulta y mantenimiento. En el ejemplo, este módulo proporciona la Base de datos donde se almacena la información de inventario y estado de estaciones de bicicletas, así como el motor de consultas.
Gis Viewers: Facilita la visualización GIS de la información almacenada en plataforma y que dispone de un componente geográfico. En nuestro ejemplo, el visor GIS permitirá crear un visor HTML que georeferencie las estaciones de la ontología de inventario.
Dashboard Engine: Permite crear y visualizar de forma gráfica, mediante componentes web HTML5, la información almacenada en la plataforma. En el ejemplo crearemos un Dashboard que muestre un visor GIS con el inventario de bicicletas georeferenciado, el estado de todas las estaciones, así como un filtro que indique la comparativa entre bicicletas eléctricas y mecánicas disponibles en cada estación de alquiler.
API Manager: Facilita la integración con otros sistemas, permitiendo que la información almacenada en la plataforma pueda ser explotada por otros sistemas, de una forma estándar y controlada mediante un API REST.

En el ejemplo crearemos un API REST con una operación que permita conocer el listado de estaciones cuyas bicicletas disponibles estén por debajo de un umbral indicado por un parámetro en el API.

Modelado de ontologías

El modelado de una ontología es inherente a la información que esta tiene que almacenar. Por lo que para crear las ontologías, consultaremos primero la información devuelta por el servicio Open Data de Bicing. En concreto, el portal Open Data es:
https://opendata-ajuntament.barcelona.cat/data/es/dataset/informacio-estacions-bicing

Y los dos recursos son:

Inventario:

https://api.bsmsa.eu/ext/api/bsm/gbfs/v2/en/station_information
Que devuelve el inventario de estaciones en el siguiente formato:

Estado:

https://api.bsmsa.eu/ext/api/bsm/gbfs/v2/en/station_status
Que periódicamente se actualiza, devolviendo el estado de cada estación en el siguiente formato:

De este modo, moderaremos dos ontologías:

BicingBCN_Inventory: Con el inventario de estaciones.

Para crear esta ontología utilizaremos una plantilla GSMA que ya define un estándar para este tipo de información y que mediante transformación previa durante la ingesta, es compatible con la devuelta por el servicio Open Data. Podemos encontrar información sobre este datamodel en la siguiente dirección:
https://fiware-datamodels.readthedocs.io/en/latest/Transportation/Bike/BikeHireDockingStation/doc/spec/index.html

Para crear la ontologia, una vez logados en la plataforma seguiremos los siguientes pasos:

- Elegir la opción de Menú: Tools > My Ontologies y a continuación el botón Create:

- Seleccionar la opción: Creation Step by Step:

- Crear la ontología indicando: nombre, descripción, meta-información y seleccionar el Template del datamodel GSMA-Bikestation:

- Pulsar Update Schema para generar el Esquema JSON de la ontología

- Finalmente pulsar New:

BicingBCN_Status: Ontología con el estado (Bicicletas disponibles) de cada una de las estaciones. En este caso no utilizaremos una plantilla de ontología, sino que la crearemos propiedad a propiedad.

Las propiedades que tendrá la ontología se basan en las devueltas por el servicio Open data y son:

station_id
numBikesAvailable
numBikesMechanical
numBikesElectric
status

El proceso para crear la ontología BicingBCN_Status es el mismo que para BicingBCN_Inventory, salvo por la plantilla, que en este caso será vacía (Template: General > Empty Base) y se añadirán las propiedades de forma manual mediante el botón add new property:

De este modo añadimos una a una las propiedades indicadas anteriormente como se puede ver en la imagen:

Finalizamos la creación de la ontología generando el esquema pulsando Update Schema y finalmente el botón New.

Una vez creadas ambas ontologías, podemos comprobar que existen, pero que no tienen datos todavía. Para ello seleccionamos la herramienta Query Tool desde Tools > Query Tool:

Localizamos la ontología BicingBCN_Inventory:

Y comprobamos mediante una sentencia de consulta que no hay datos:

Del mismo modo si consultamos la ontología BicingBCN_Status, comprobamos que tampoco tiene datos:

Ingesta de datos

Al crear las ontologías, ya hemos adelantado los servicios Open Data y el formato de la información que devuelven. En la ingesta, vamos a crear dos flujos de información, uno por cada servicio, que consultará la información, la transformará al formato semántico de la ontología definida, y la almacenará en la ontología correspondiente.
Para crear los flujos accedemos al Flow Engine de la plataforma desde el menú Tools > My IoT Flows

En caso de haber creado ningún flujo previamente, nos aparecerá un listado vacio:

En este caso, tendremos que crearnos una instancia del motor de flujos pulsando el botón Create. Desde donde podremos dar una identificación a nuestra instancia y crearla pulsando New:

Esto instanciará nuestro motor de flujos, que procederemos a arrancar pulsando Start:

Una vez arrancado, accederemos al editor de flujos pulsando View it:

Apareciendo de este modo el editor de flujos:

Flujo de ingesta de Inventario de estaciones:

A continuación, programaremos un flujo que diariamente se conectará al servicio Open Data, consultará las estaciones inventariadas, convertirá dicha información al modelo semántico de la plataforma (ontología BicingBCN_Inventory) y la almacenará en la ontología.
Pasos:

Lanzamiento periódico del flujo: Programaremos la ejecución periódica del flujo mediante un nodo de tipo inject.

Localizamos el nodo en la paleta:

Y lo arrastramos al grid:

A continuación hacemos doble click sobre el nodo para acceder a su configuración:

Lo configuramos para que se ejecute todos los días a las 06:00 y pulsamos Done:

Invocación al servicio Open Data: La siguiente etapa en el flujo es recuperar la información de estaciones desde el servicio Open Data. Como vimos anteriormente, esto se consigue invocando a la url: https://api.bsmsa.eu/ext/api/bsm/gbfs/v2/en/station_information

Para ello utilizaremos un nodo de tipo Http Request.
Localizamos el nodo en la paleta:

Y lo arrastramos al grid:

A continuación hacemos doble click sobre el mismo para establecer su configuración, indicamos la url a la que tiene que invocar y pulsamos Done:

Finalmente establecemos la conexión con el nodo anterior para conectarlo al flujo:

Una vez conectado, podemos testear el flujo verificando que la salida del nodo http request es la respuesta del servicio Open Data. Para ello, le conectamos un nodo de tipo debug. Este nodo muestra en la consola de debug de la herramienta el mensaje de salida del nodo que se le conecta:

A continuación desplegamos el flujo pulsando Deploy:

Y podemos probarlo habilitando la pestaña debug y pulsando el botón del nodo inject.

Conversión de la información al modelo semántico de la ontología: La información recuperada del servicio Open Data es una lista de estaciones con el siguiente formato cada una:

Y para almacenarlas en la plataforma tenemos que convertirla al modelo definido en la ontología BicingBCN_Inventory, donde las instancias deben tener la siguiente estructura:

Para ello haremos lo siguiente en el flujo:
Convertiremos la respuesta del servicio Open Data, que es un String con el JSON de la respuesta, a un modelo de objetos JSON puro. Para ello conectaremos un nodo de tipo Json, que hace precisamente esto, convertir la respuesta del servicio en un array de objetos JSON.

A continuación procesaremos el array de estaciones con el formato del servicio Open Data, convirtiéndolo en un array de estaciones con el formato de la ontología BicingBCN_Inventory. Para ello utilizaremos un nodo de tipo function, que nos permite programar lógica en Javascript:

Hacemos doble click sobre el nodo de tipo function recién añadido para configurarlo, incluyendo el siguiente código, que realiza el procesamiento de transformación indicado anteriormente y pulsamos Done:

var stations=msg.payload.data.stations; 
var gsmaStations=[]; 
for(i=0;i<stations.length;i++){
var station ={BikeHireDockingStation : {
id: ""+stations[i].station_id,
type: "BikeHireDockingStation",
name: ""+stations[i].name,
category: ""+stations[i].physical_configuration,
status: "ON",
availableBikeNumber: stations[i].capacity,
freeSlotNumber: stations[i].capacity,
totalSlotNumber: stations[i].capacity,
location: {
coordinates: [stations[i].lon, stations[i].lat],
type: "Point"
},
address: ""+stations[i].address,
description: ""+stations[i].physical_configuration,
dateModified: "03-04-2019",
ownership:"Ayto Barcelona"
}
};
gsmaStations[i]=station;
} 
msg.payload=gsmaStations;
return msg;

Inserción en plataforma: Una vez convertida la información al formato de la ontología, ya se puede almacenar en plataforma.

Incluimos en el flujo un nodo de tipo onesaitplatform-insert:

Hacemos doble click sobre el nodo, configuramos la ontología BicingBCN_Inventory como destino de la información y pulsamos Done:

Añadimos un nodo tipo debug para visualizar el resultado de la inserción en la pestaña de debug, que al tratarse de una inserción, es el numero de elementos insertados en plataforma. Tras desplegar y testar podemos ver:

Borrado de registros previos: Como vimos al iniciar el flujo, se trata de un flujo que se ejecutará periódicamente todos los días. Por lo que en cada ejecución deberíamos actualizar el inventario. La forma más sencilla es borrando previamente las estaciones de la última ejecución del flujo y volviendo a cargar las de la ejecución actual. Para ello añadiremos otro nodo al flujo para el borrado previo de estaciones justo al lanzarse el flujo.

Para ello añadimos un nodo de tipo onesatiplatform-query-static y lo conectamos al nodo inicial (aprovechamos también para añadir un nodo de tipo debug para visualizar el resultado).

Hacemos doble click sobre el nodo onesaitplatform-query-static y configuramos la ontología que queremos borrar: BicingBCN_Inventory y la sentencia SQL: delete from BicingBCN_Inventory. Pulsamos Done.

Volvemos a desplegar y comprobamos en la pestaña de debug que previamente se borra la información anterior y posteriormente se almacena la nueva:

Verificación de inserción: Comprobamos en plataforma que la información se ha insertado de forma correcta en la ontología. Para ello accedemos a Tools > Query tool y lanzamos una sentencia de consulta sobre la ontología BicingBCN_Inventory:

Flujo de ingesta de estado de estaciones: El flujo de ingesta del estado de las estaciones es muy parecido al anterior. Requiere de los mismos nodos, solo que cambiando el servicio origen de los datos y la ontología destino BicingBCN_Status, por lo no entraremos tanto en detalle.

Pasos:

Crear un nuevo flujo: Pulsar el botón
para añadir una nueva pestaña con un nuevo grid en blanco para definir otro flujo.

Lanzamiento periódico del flujo: Programaremos la ejecución periódica del flujo mediante un nodo de tipo inject. Al tratarse del estado de las estaciones, configuraremos el nodo para que se ejecute cada 15 minutos:

Invocación al servicio Open Data: La siguiente etapa en el flujo es recuperar la información de estado de las estaciones desde el servicio Open Data, invocando mediante un nodo Http Request a la url: https://api.bsmsa.eu/ext/api/bsm/gbfs/v2/en/station_status

Conversión de la información al modelo semántico de la ontología: La información recuperada del servicio Open Data es la lista de estaciones con su estado, en el siguiente formato cada una:

Y para almacenarlas en la plataforma tenemos que convertirla al modelo definido en la ontología BicingBCN_Status, donde las instancias deben tener la siguiente estructura:
Para ello haremos lo siguiente en el flujo:
Convertiremos la respuesta del servicio Open Data, que es un String con el JSON de la respuesta, a un modelo de objetos JSON puro. Para ello conectaremos un nodo de tipo Json, que hace precisamente esto, convertir la respuesta del servicio en un array de objetos JSON.

A continuación procesaremos el array de estado de estaciones con el formato del servicio Open Data, convirtiéndolo en un array de estaciones con el formato de la ontología BicingBCN_Status. Para ello utilizaremos de nuevo un nodo de tipo function, que nos permite programar lógica en Javascript:

Hacemos doble click sobre el nodo de tipo function recién añadido para configurarlo, incluyendo el siguiente código, que realiza el procesamiento de transformación indicado anteriormente y pulsamos Done:

var stations=msg.payload.data.stations; 
var ontologyStations=[]; 
for(i=0;i<stations.length;i++){
var station= {BicingBCN_Status: { 
station_id:""+stations[i].station_id,
numBikesAvailable:stations[i].num_bikes_available,
numBikesMechanical:stations[i].num_bikes_available_types.mechanical,
numBikesElectric:stations[i].num_bikes_available_types.ebike,
status:stations[i].status
}
}; 
ontologyStations[i]=station;
} 

msg.payload=ontologyStations;
return msg;

Inserción en plataforma: Una vez convertida la información al formato de la ontología, ya se puede almacenar en plataforma.

Incluimos en el flujo un nodo de tipo onesaitplatform-insert y lo configuramos para que almacene la información en la ontologia BicingBCN_Status.

Añadimos un nodo tipo debug para visualizar el resultado de la inserción en la pestaña de debug, que al tratarse de una inserción, es el número de elementos insertados en plataforma. Tras desplegar y testar podemos ver:

Borrado de registros previos: Del mismo modo que en el flujo anterior, tenemos que borrar la información previamente insertada en cada ejecución del flujo, de manera que configuramos el borrado de la ontología BicingBCN_Status con un nodo onesaitplatform-query-static:

Desplegamos y verificamos la respuesta en la pestaña de debug.

Verificación de inserción: Comprobamos en plataforma que la información se ha insertado de forma correcta en la ontología. Para ello accedemos a Tools > Query tool y lanzamos una sentencia de consulta sobre la ontología BicingBCN_Status:

Visor GIS con inventario de estaciones:

Lo siguiente que haremos será crear un Visor GIS con una capa, que represente las estaciones de bicicletas inventariadas en la ontología BicingBCN_Inventory.
Pasos:

Crear una capa GIS a partir de la ontología BicingBCN_Inventory. Para ello acceder a la opción de menú Gis Tools > My Gis Layers y en la pantalla pulsar el botón Create:

A continuación seleccionar Creation Ontology Layer:

En el siguiente formulario asignar un identificador y descripción a la capa, así como seleccionar la ontología a representar (BicingBCN_Inventory). Automáticamente al seleccionar la ontología se propondrán los campos de geometrías que tenga la ontología, para que el usuario seleccione aquel con el que quiere representar. En nuestro caso el campo es location:

Seguidamente en la pestaña Symbology seleccionamos la representación por defecto que tendrán nuestras instancias de la ontología sobre el visor:

Y en el campo Info Box seleccionamos los atributos de la ontologia a representar en el popup que se abrirá al pulsar sobre cada elemento.

Finalmente pulsamos sobre New para crear la capa, que ya nos aparecerá en el listado inicial de capas.

A continuación creamos el visor con la capa. Seleccionar la opción de menú Gis Tools > My Gis Viewers y en la pantalla seleccionar el botón Create:

En el formulario indicar el identificador y descripción del visor, seleccionar la tecnología (de momento Cesium), la capa base del visor y la capa creada anteriormente. Automaticamente se creará el visor, con su código fuente y se podrá visualizar en la propia pantalla:

Pulsar New para crear el visor.
De este modo nos aparecerá en el listado de visores disponibles:

Y entre otras cosas podremos consultar la url en la que lo sirve la plataforma y que puede ser consultada desde cualquier navegador:

Dashboard consumiendo la información

A continuación crearemos un Dashboard que consumirá la información de las ontologías anteriores. Integrará un visor GIS con el inventario de estaciones, mostrará una tabla con el estado de las estaciones y permitirá seleccionando una estación hacer una comparativa entre el número de bicicletas mecánicas y eléctricas disponibles.

El aspecto final del dashboard será similar al siguiente:

Pasos:

Crear el dashboard: Seleccionar la opción de menú Visualizacion > My Dashboards y pulsar Create:

Registrar el Dashboard en plataforma: En la siguiente pantalla basta con asignar un identificador y descripción al dashboard:

Editar componentes del Dashboard: Al crear el Dashboard se nos abrirá un editor con un grid en blanco para empezar a añadir componentes:

Incluir Gadget con visor GIS: El primer Gadget que incluiremos será un visor GIS con el inventario de estaciones. Para ello pulsaremos el botón
que permite añadir elementos al grid del Dashboard. Con ello se desplegará en la parte inferior de la pantalla un asistente que permite añadir Gadgets al dashboard:

Como se puede apreciar, vemos que ya existe un componente mapa, por lo que arrastramos este componente al grid.
A continuación se nos abrirá un pop-up para que indiquemos si queremos incluir un Gadget ya existente (creado previamente) o crear uno nuevo. Elegiremos New Gadget:

En el siguiente formulario, asigna un identificador al Gadget y selecciona la ontología donde está la información geográfica a mostrar:

Hecho esto podremos construir una sentencia de tipo query que indica al Gadget que sentencia tiene que lanzar para recuperar la información a mostrar en el mapa. En nuestro caso utilizaremos select * from BicingBCN_Inventory as c limit 400:

Pulsando Continue pasamos a la siguiente pantalla, donde asociamos los campos recuperados de la sentencia anterior a su representación en el visor. En concreto indicamos el campo que proporciona la latitud y longitud, el identificador de cada instancia, así como las propiedades que se mostrarán en el popup de cada elemento:

Pulsando New terminamos la creación del Dashboard y podemos verlo sobre el grid del dashboard:

En este punto es conveniente salvar el trabajo realizado pulsando

Incluir Gadget con tabla con el estado de cada estación: Para este Gadget vamos a cruzar mediante un sencillo JOIN SQL, información de las ontologías BicingBCN_Status y BicingBCN_Inventory, ya que la ontología BicingBCN_Status no dispone del nombre de las estaciones.

Ademas, este gadget se refrescará periódicamente, para reflejar los cambios de estado. Recordemos que el flujo que actualiza la ontología BicingBCN_Status se refresca cada 15 minutos.
Para poder hacer todo esto, necesitamos de forma previa a la creación del Gadget, crear un datasource que proporcione la información y refresco de la misma al Gadget.
Para crear el Datasource del Gadget Tabla accedemos en el menú de plataforma a Visualizations > My Datasources y pulsamos el botón Create:

A continuación asignamos un identificador al Datasource, seleccionamos una ontología, le damos un tiempo de refresco de 15 minutos y le asociamos la sentencia SQL que proporciona la información de las dos tablas:

select inv.BikeHireDockingStation.name as name, st.BicingBCN_Status.numBikesAvailable as numBikesAvailable, st.BicingBCN_Status.numBikesMechanical as numBikesMechanical, st.BicingBCN_Status.numBikesElectric as numBikesElectric, st.BicingBCN_Status.status as status from BicingBCN_Status as st JOIN BicingBCN_Inventory as inv ON st.BicingBCN_Status.station_id=inv.BikeHireDockingStation.id

Una vez creado el Datasource, volvemos al editor del dashboard y añadimos un nuevo gadget de tipo tabla:

De nuevo seleccionamos New Gadget en el popup:

Asociamos un identificador al Gadget y seleccionamos el Datasource creado anteriormente (dsBicingBcnStatus):

A continuación bajamos a la sección measures y añadimos los campos a mostrar en la tabla, que se corresponden con los indicados en la sentencia y que podemos mapear a un titulo para la columna de la tabla. Dinámicamente veremos como se van añadiendo a la tabla:

Finalmente pulsando New se creará el gadget y se verá en el grid del Dashboard:

Incluir combo de selección de estación: A continuación añadiremos una combo que nos permitirá seleccionar una estación.

Examinando los gadgets comprobamos que no existe ningún gadget tipo combo, pero este puede ser añadido como uno de tipo Template, que es un tipo especial de Gadget que permite crear plantillas reutilizables a partir de código HTML.
Para este Gadget primero crearemos el datasource. En este caso necesitamos el nombre de cada estación, que recuperaremos de la ontología BicingBCN_Inventory
Para crear el Datasource del Gadget Combo accedemos en el menú de plataforma a Visualizations > My Datasources y pulsamos el botón Create

A continuación asignamos un identificador al Datasource, seleccionamos una ontología y creamos la sentencia de consulta que alimentará al combo:

Una vez creado el Datasource, volvemos al editor del dashboard y añadimos un nuevo gadget de tipo Template:

En el popup seleccionamos No para indicar que vamos a crear un nuevo gadget de tipo Template:

Con esto se crea el Gadget vacio:

Procedemos a editarlo seleccionando Edit:

En la siguiente pantalla indicamos el datasource creado anteriormente (dsBicingBcnStations), y en el código HTML, el siguiente código, que itera en el resultado del datasource y muestra el nombre de cada estación:

Pulsamos Compile &Synchronize y Close y ya tendremos disponible la combo en el grid del Dashboard:

Incluir comparador de bicicletas disponibles: El siguiente componente a incluir es un diagrama de barras, que una vez seleccionada una estación en la combo muestre en dos barras las bicicletas disponibles clasificadas como mecánicas y eléctricas

De nuevo empezaremos por el datasource del gadget. En este caso necesitamos extraer de la ontología BicingBCN_Status, el número de bicicletas eléctricas y mecánicas disponibles, agrupando por el identificador de la estación.
Para crear el Datasource del Gadget Combo accedemos en el menú de plataforma a Visualizations > My Datasources y pulsamos el botón Create:

A continuación asignamos un identificador al Datasource, seleccionamos una ontología y creamos la sentencia de consulta que alimentará al combo:

Una vez creado el Datasource, volvemos al editor del dashboard y añadimos un nuevo gadget de tipo Bar Chart:

En el popup elegimos New Gadget y a continuación asignamos un identificador al Gadget y elegimos el Datasource creado previamente (dsBicingBCNAvailables):

A continuación, en la sección measure se indican las columnas a mostrar a partir de los atributos recuperados de la query del Datasource. En concreto serán dos columnas: Bicicletas mecánicas y Bicicletas eléctricas (Eje X) agrupadas ambas por el id (Eje Y):

Una vez creado el Gadget aparece en el grid del dashboard:

- Asignar Estilo y títulos: Lo siguiente es ponerle a cada Gadget un titulo correcto. Para ello en cada gadget elegir la opción Styling:

Y cambiar el titulo en el atributo Gadget Title:

Además, en el gadget del diagrama de barras vemos que no tiene mucho sentido mostrarlo si no se filtrado previamente en la combo, por lo que le marcaremos la opción Show Gadget only when it is filtered:

Asociar filtrado en combo con gadget de comparación: Por último, crearemos la asociación que permite filtrar el combo de estaciones, con el comparador de mecánicas-electricas disponibles en cada una.

Para ello, seleccionamos crear un Datalink, pulsando el botón:
A continuación se nos abre un formulario en el que podemos establecer la asociación entre el Gadget Origen y el Gadget Destino, indicando el atributo de filtrado. En nuestro caso, el origen es el Gadget de la combo y el destino es el Gadget de barras, en ambos casos el atributo de filtrado es id:

Añadimos pulsando de manera que aparezca entre las conexiones existentes:

Cerramos y salvamos el Dashboard.

Probar el Dashboard: Una vez finalizado el dashboard podemos probarlo accediendo a su url. Para conocer su url seleccionamos en el menú Visualizations > My Dashboards, de manera que nos aparezca en la tabla

Y seleccionamos la opción para conocer su url:

API Rest de consulta

Vamos a utilizar el API Manager la plataforma para crear un API REST que permita conocer que estaciones tienen disponibles bicicletas por debajo de un umbral pasado por parámetro. Para ello crearemos una operación que consulte mediante una sentencia SQL en la ontología BicingBCN_Status, que estaciones están por debajo del umbral

Pasos:
Accedemos al API Manager desde el menú de la plataforma Tools > My Apis y seleccionamos Create:

En el formulario indicamos los datos del API: Identificación, categoria, descripción, meta-inf, así como seleccionamos que se trata de una Ontologia como API REST, e indicamos que la ontología expuesta es BicingBCN_Status:

A continuación indicamos que vamos a crear una operación de tipo Custom Query:

Y en el formulario que se abre completamos el identificador de la operación, la sentencia SQL parametrizada, el tipo de datos del parámetro y la descripción de la operación:

Al salvar, volveremos a la pantalla principal y tendremos la nueva operación:
Si guardamos el API, esta estará creada y se podrá invocar a la operación recién creada. Para ello:
Recuperamos el token del usuario: Desde la opción de menú Tools > My Apis y seleccionando la pestaña User Tokens:

Probamos el API: Desde la opción de menú Tools > My Apis, localizando el API en el listado y seleccionando la opción SWAGGER:

En la siguiente pantalla, nos aseguramos que el esquema es HTTPS:

Desplegamos la operación y la probamos con Try it out:

Introducimos el token recuperado previamente, el parámetro por el que queremos filtrar, y ejecutamos:

platform-doc-es

Workshop de ingesta desde un portal Open Data, visualización con dashboards y apificación