1. Home
  2. HOW to use Snap4City tools for dummies

HOW to use Snap4City tools for dummies

 

In this document you can find for each snap4city tools, with its main functionalities and uses.

The Snap4City Entity Directory, also referred to in the documentation as the IoT Directory, is essentially the platform component used to manage the models, instances, brokers, and lifecycle of IoT/digital-twin entities. It provides a layer of abstraction over different device types, protocols, brokers, and data formats. 

Main functionalities of Entity Directory also called IoT Directory are:

  • Entity/Data Model management. Users can browse, create, register, clone, import/export, and manage Entity Models / IoT Device Models, including Snap4City models, FIWARE Smart Data Models, and custom models. Models work like classes or templates that define the attributes and structure of entity instances.

  • Entity instance / IoT device management. From those models, users can create and register concrete Entity Instances / IoT Devices, either manually or through APIs, IoT Apps, bulk tools, or broker harvesting. Instances can subsequently be modified, managed, or logically deleted/recovered.

  • IoT broker management. The directory registers and manages brokers associated with entities. It supports both Snap4City-managed internal brokers and external third-party brokers. External Orion brokers, for example, can be connected and harvested so their existing entities become registered in Snap4City.

  • FIWARE/NGSI integration. It integrates strongly with FIWARE Orion, including NGSI V1/V2/LD concepts, services/tenants, and service paths. Snap4City can also deploy Orion brokers on demand.

  • Multi-protocol interoperability. It helps hide differences among IoT technologies and communication mechanisms. The wider Snap4City ingestion architecture supports protocols such as MQTT, NGSI, CoAP, OneM2M, ModBus, OPC, AMQP, WMS and WFS, among others.

  • The Entity Directory exposes APIs that applications can use to register devices/entities, perform queries, and manage resources programmatically. Other APIs, such as Orion/NGSI, are then used for sending entity updates and messages.

  • Integration with the Knowledge Base. Registering models and entities connects them to Snap4City's semantic Knowledge Base, allowing relationships between entities and other city resources to be represented and queried rather than treating devices as isolated records.

  • Ownership and access management. Entities and models have owners; the Entity Directory supports changing ownership and delegating access to Entity Models and Entity Instances/IoT Devices according to Snap4City's access-control model.

A useful mental model is:

Entity Model → Entity Instance → Entity Messages / Time Series

For example, you might define a WeatherStation model containing temperature, humidity, and location; create WeatherStation_001 as an instance; associate it with an MQTT/Orion broker; and then continually receive messages that change its temperature and humidity values. Snap4City can store those evolving values as time series and make the entity available to dashboards, analytics, IoT Apps, and digital-twin applications.

So, in one sentence: the Entity Directory is Snap4City's central registry and management layer for defining what entities look like, creating their instances, connecting them to brokers/protocols, controlling access, and integrating them with the rest of the Snap4City knowledge and IoT ecosystem.

Entity Directory also called IoT Directory can be accessed using:

Main functionalities of Processing Logic also called IoT App are:

In Snap4City, Process Logic (Proc.Logic) is the platform’s server-side business-logic and workflow layer. It is implemented mainly through Node-RED plus Snap4City microservice libraries, so applications can be built visually as data flows rather than entirely through custom code. Snap4City describes it essentially as:

Proc.Logic = Node-RED + Snap4City MicroServices Libraries. (Snap4City)

Process Logic (Proc.Logic) main functionalities are:

  • Data ingestion and integration. Proc.Logic can collect data from IoT devices, brokers, APIs, databases, external services and other platforms, using push or pull mechanisms and multiple protocols and formats. (Snap4City)

  • Data transformation and enrichment. Flows can filter, aggregate, normalize, convert, translate and enrich incoming data, as well as establish relationships among entities before storing or exposing the results. (Snap4City)

  • Workflow and business-rule implementation. Developers can visually define conditions, decisions, event handling and sequences of operations. Process Logic can therefore act as the server-side business logic behind dashboards and smart applications. (Snap4City)

  • Event-driven and scheduled processing. A flow can run in real time when an event occurs, quasi-real time, periodically, on demand, or as a batch/back-office process. (Snap4City)

  • IoT device and Digital Twin interaction. Proc.Logic can read entity data, manipulate Digital Twin information and interact with sensors, actuators, gateways and IoT brokers. Logic can also be deployed at the edge, not only in the cloud. (Snap4City)

  • Dashboard interaction. Dashboard widgets can trigger Proc.Logic flows, while flows can calculate or retrieve information and send results back to dashboards. This supports interactive applications, buttons, switches, synoptics, charts and other user-interface components. (Snap4City) (this feature is only for prototyping not for production)

  • Data analytics and AI orchestration. Process Logic can invoke analytics, prediction models, optimization, simulations, anomaly detection and other AI/ML services. It can also call custom Python or R processes exposed as microservices and integrate them into larger workflows. (Snap4City)

  • Geospatial and mobility processing. Available microservices include GIS operations, reverse geocoding, GPS calculations, routing, multimodal routing, traffic analysis and other location-based services. (Snap4City)

  • External-service integration and notifications. Flows can communicate with web services and APIs and can manage mechanisms such as email, Telegram, WebSockets, FTP and other event-distribution channels. (Snap4City)

  • Platform and process management. Microservices are available for managing Proc.Logic processes themselves, including operations such as restart, upgrade, ownership management, authorization, logs and remote access to edge installations. (Snap4City)

  • Development and debugging. Snap4City extends Node-RED with debugging facilities such as message inspection, breakpoints, step-by-step execution, message-history inspection and value monitoring, which are useful for developing complex Digital Twin workflows. (Snap4City)

A simple example is:

Sensor → Proc.Logic → Analytics → Decision → Actuator/Dashboard

For example, a temperature sensor could publish a value to an IoT broker. A Proc.Logic flow reads it, validates and stores it, calculates a moving average, calls an anomaly-detection model, and, if a threshold is exceeded, sends an alert, changes an actuator and updates a dashboard.

So the relationship with the component you asked about previously is roughly:

Entity Directory → defines and manages what the entities/devices are
Process Logic → defines what the system does with their data and events
Dashboards → provide the user-facing visualization and interaction

This makes Process Logic essentially the orchestration and automation engine of a Snap4City application or Digital Twin. Recent Snap4City material describes more than 190–200 specialized microservices covering areas such as entity management, IoT, storage, analytics, GIS, dashboards, events, external services and AI. (Snap4City)

Process Logic development can be accessed by using the following link and click on [create new] button on top right corner.

https://www.snap4city.org/dashboardSmartCity/management/iotApplications.php?pageTitle=IOT%20Applications&linkId=iotAppsLinkddd&fromSubmenu=iotAppsLinka2 

In Snap4City, the Dashboard Builder is the main visualization and user-interaction layer. It is used to create interactive dashboards and smart-application interfaces with little or no coding, primarily by composing and configuring widgets on a graphical canvas. Snap4City describes three core parts: the Widget Collection, Dashboard Wizard, and Dashboard Editor. (Snap4City)

Dashboard Builder main functionalities are:

  • Visual dashboard creation. Users can create dashboards graphically by placing, resizing and configuring widgets on a canvas. Dashboards can range from simple monitoring pages to complex control-room and decision-support interfaces. (Snap4City)

  • Large library of visualization widgets. It provides widgets such as time-series charts, gauges, speedometers, histograms, bar and pie charts, tables, KPIs, selectors, traffic-light indicators, heatmaps, lists and other specialized visual components. (Snap4City)

  • Dashboard Wizard. The wizard helps users rapidly associate available data with appropriate widgets. It considers factors such as the data type, semantic model, geographic location and organization, reducing the effort required to construct a dashboard. (Snap4City)

  • Real-time and historical data visualization. Dashboards can display stored historical information as well as live data from IoT devices, IoT applications, WebSockets and other streaming sources. (Snap4City)

  • Integration with multiple data sources. The Builder can access data coming from Snap4City APIs and repositories including Smart City APIs, Elasticsearch, MongoDB, MySQL, IoT brokers and federated data sources. (Snap4City)

  • Geospatial visualization. It supports map-based dashboards using technologies such as OpenStreetMap, ServiceMap/ServiceMap3D and Google Maps, with functionality such as entity visualization, tracks, heatmaps, shapes, geographic drill-down and historical information. (Snap4City)

  • Interactive dashboards. Widgets are not limited to displaying information. They can interact with one another—for example, selecting something in one widget can change the information displayed in a map or chart. (Snap4City)

  • IoT control and actuation. Widgets can represent actuators, switches and other controls, allowing a dashboard to both receive information from the platform and send commands or data back to IoT applications and external systems. (Snap4City)

  • Integration with Process Logic. Dashboards can interact with server-side business logic implemented through Snap4City Process Logic/Node-RED, while client-side logic can also be implemented with JavaScript when more advanced behavior is required. (Snap4City)

  • Custom widgets. Developers can extend the standard widget collection with custom widgets for specialized visualizations, animations or application-specific user interfaces. (Snap4City)

  • Dashboard management and reuse. Dashboards and widgets can be created, edited, imported, exported, deleted and cloned. Cloning also makes it practical to reuse an existing dashboard as the basis for another one. (Snap4City)

  • Sharing and access control. Dashboards can be public or private, shared with specific users, delegated and protected through Snap4City's authentication and authorization mechanisms, including SSO/LDAP integration. (Snap4City)

  • Responsive and multi-device visualization. Dashboards are HTML5/JavaScript based and can adapt to devices ranging from smartphones and tablets to large UHD control-room screens. (Snap4City)

  • Embedding in other applications. Dashboards can be embedded into third-party web pages and applications, allowing Snap4City visualizations to become part of external portals or services. (Snap4City)

  • Support for external services and MicroApplications. Dashboards can incorporate services such as routing, public-transport information, parking forecasts, traffic information, pollution monitoring and other Snap4City MicroApplications. (Snap4City)

A simple example would be:

IoT sensor → Entity Directory → Process Logic → Dashboard Builder

A traffic sensor could be registered in the Entity Directory, its values processed by Process Logic, and then displayed in Dashboard Builder using a map, real-time chart and KPI. A user could select a road segment on the map, causing other widgets to show its historical traffic trend, while an interactive control could trigger a Process Logic workflow.

So the three components you have asked about can be summarized as:



Snap4City component

Main role

Entity Directory

Defines and manages entities, devices, models and brokers

Process Logic

Implements processing, automation, orchestration and business logic

Dashboard Builder

Implements visualization, monitoring and user interaction

 

In other words, Entity Directory defines what exists, Process Logic defines what happens, and Dashboard Builder defines what users see and interact with. This separation is one of the main architectural ideas behind building Snap4City smart-city and Digital Twin applications. (Snap4City)

Dashboard Builder can be accessed by using the following link and clicking on [new dashboard] button on top right corner.

In Snap4City, CSBL means Client-Side Business Logic. It is the mechanism used to make dashboards and smart applications interactive and context-aware directly in the user's browser, without requiring every interaction to be processed by server-side Process Logic. (Snap4City)

Its main functionalities are:

  • Widget-to-widget interaction. CSBL allows an action performed on one dashboard widget to modify one or more other widgets. For example, clicking a slice of a pie chart can update a table, map, or time-series chart with more detailed information. (Snap4City)

  • Event handling from user actions. JavaScript logic can react to events such as clicks, selections, map interactions, time-range selections, switches, knobs, buttons, and other widget-specific events. (Snap4City)

  • Dynamic modification of widget content. CSBL can change what a widget displays, including its data, rendering, position, zoom level, content, and in some cases graphical properties such as colors. (Snap4City)

  • Client-side data processing. Business logic is executed directly in the browser, so calculations and interaction logic can be performed independently for each connected user. This can reduce computational workload on the server and naturally maintains a separate interaction context for each user. (Snap4City)

  • JavaScript-based business logic. CSBL logic can be written in JavaScript associated with dashboard widgets. Snap4City also provides a visual CSBL editor to simplify development for some interactions. (Snap4City)

  • Data filtering and drill-down/drill-up. Users can select a portion of data and propagate that selection to other visualizations. Typical examples include spatial drill-down on maps and temporal drill-down on time-series data. (Snap4City)

  • Time synchronization among widgets. Selecting a time interval in one chart can cause other charts to display the same time window, making CSBL particularly useful for interactive business-intelligence analysis. (Snap4City)

  • Map interaction. A selection on a map can drive other visualizations. For example, selecting a geographic object or PIN can trigger charts or tables showing information related to that object. (Snap4City)

  • Calling Snap4City APIs. CSBL can query platform data using Snap4City APIs, allowing widgets to dynamically retrieve additional information according to user actions. (Snap4City)

  • Calling external APIs and services. Since CSBL runs JavaScript in the dashboard context, it can also invoke appropriate third-party APIs or services—for example, REST services—to retrieve information and update the dashboard. (Snap4City)

  • Opening and controlling other dashboards. An interaction in one dashboard can open another dashboard and pass information or control its behavior, enabling more complex multi-view applications. (Snap4City)

  • Interactive controls and actuation. CSBL supports widgets such as buttons, switches, knobs, and numeric keyboards. These can generate commands or trigger actions based on user interaction. (Snap4City)

  • Business-intelligence interfaces. CSBL is specifically suited to highly interactive BI applications in which the information and visual representation evolve dynamically according to what the user selects or does. (Snap4City)

  • Integration with Server-Side Business Logic. CSBL and SSBL can coexist in the same dashboard. Simple, user-specific interactions can remain client-side, while heavier computations, analytics, database processing, or IoT operations can be delegated to Process Logic/Node-RED on the server. (Snap4City)

  • Interaction history / Time Machine support. The CSBL framework also includes functions for maintaining an undo stack and supporting "Time Machine" behavior in business-intelligence applications. (Snap4City)

A typical example would be:

User clicks a road on a map → CSBL receives the event → queries data → updates a time-series chart + KPI + table

All of this can happen inside the browser, without invoking a Node-RED workflow for every interaction.

The distinction between the components you've asked about can therefore be summarized as:



Component

Main responsibility

Entity Directory

Defines and manages entities, devices, models and brokers

Process Logic / SSBL

Performs server-side processing, workflows, automation and orchestration

Dashboard Builder

Creates the visual user interface and widgets

CSBL

Defines dynamic interactions and business logic between dashboard widgets on the client side

 

A useful way to think about the architecture is:

Data / Entities → Process Logic → Dashboard → CSBL → User interaction

and sometimes the flow goes back:

User → CSBL → Widget/API/Process Logic → Data or actuator

The important distinction is therefore where the logic executes:

CSBL → browser / client side / JavaScript

SSBL → server side / Process Logic / Node-RED

Snap4City explicitly supports using both at the same time, so CSBL is particularly useful for fast UI interactions, filtering, drill-down, and visualization changes, while SSBL is better suited to persistent workflows, complex analytics, integration, and server-side processing. (Snap4City)

You can access to CSBL functionalities if you are AreaManager and you have been an authorized developer. 

In Snap4City, ServiceMap is the main geospatial and semantic exploration interface for the Knowledge Base. It lets developers visually discover city entities, inspect their relationships and real-time data, and generate queries that can later be reused in dashboards, IoT applications, or APIs. Snap4City explicitly describes it as a visual tool for navigating the Knowledge Base and learning/building Smart City API queries. (Snap4City)

Its main functionalities are:

  • Geographical discovery of city entities. ServiceMap can search and visualize entities such as POIs, services, IoT devices, sensors, streets, areas and other geo-referenced resources stored in the Snap4City Knowledge Base. (Snap4City)

  • Geospatial queries. Users can search for entities around a point, inside an area, inside a polygon/polyline-defined region, or along a path/polyline, with filters such as service category and maximum distance. (Snap4City)

  • Semantic search and classification. Resources can be filtered by semantic categories and subcategories—for example mobility, accommodation, environment, energy or cultural services—rather than relying only on geographic coordinates. (Snap4City)

  • Full-text search. ServiceMap supports keyword searches over textual information associated with geo-located entities. Searches can also be combined with geographic position and category filters. (Snap4City)

  • Address and street search. It can locate streets, civic numbers and addresses. Snap4City also documents fuzzy matching, allowing partially incorrect or incomplete street names to produce useful matches. (Snap4City)

  • Entity detail inspection. Selecting an entity provides access to its properties and detailed information, including available real-time data and associated resources. (Snap4City)

  • Semantic relationship exploration. From an entity, users can inspect relationships with other entities in the Knowledge Base and move toward tools such as LOG (Linked Open Graph) for deeper exploration of RDF triples and semantic relationships. (Snap4City)

  • Real-time data exploration. ServiceMap can expose information associated with sensors and services such as public transport, pollution, weather, traffic and other dynamically changing city data. (Snap4City)

  • Public-transport exploration. Depending on the configured ServiceMap, users can inspect agencies, lines, routes, stops/stations and current vehicle positions. (Snap4City)

  • Routing and path search. ServiceMap can support path queries between selected locations, including modes such as car and public transport, together with geometric representation of the resulting route. (Snap4City)

  • Event search. Some ServiceMap configurations allow users to discover events within a selected geographic area and time period. (Snap4City)

  • ServiceURI discovery. Every Knowledge Base entity has a unique ServiceURI. ServiceMap lets developers retrieve that identifier so the entity can subsequently be referenced from Node-RED/Process Logic, dashboards or other Snap4City components. (Snap4City)

  • Smart City API query generation. One of its particularly important developer functions is converting a graphical search into the corresponding API query. Searches can be saved or represented as JSON/HTML and, where supported, assigned a Query ID for reuse. (Snap4City)

  • Dashboard integration. Queries and Query IDs produced with ServiceMap can be reused in Dashboard Builder, for example to configure selectors and dynamically retrieve sets of city entities. (Snap4City)

  • IoT App / Process Logic integration. ServiceMap can be used to discover the entities and ServiceURIs needed by Snap4City microservices and Node-RED-based IoT applications. (Snap4City)

  • Geometry and shape testing. Developers can test geographic shapes represented in formats such as WKT, which is useful when defining areas for spatial queries. (Snap4City)

A simple example is:

Select an area on the map → choose “Parking” → ServiceMap searches the Knowledge Base → parking entities appear → select one → inspect its metadata and real-time availability → retrieve its ServiceURI or API query → reuse it in Dashboard Builder or Process Logic.

This also helps distinguish ServiceMap from the other Snap4City components you asked about:



Component

Main role

Entity Directory

Defines and manages entities, devices, models and brokers

Process Logic

Implements server-side processing, workflows and automation

Dashboard Builder

Builds visualization and user interfaces

CSBL

Implements client-side dashboard interactions

ServiceMap

Discovers, searches and explores city entities geographically and semantically, even on multiple knowledge based and tenants

 

So, in compact form:

ServiceMap = Map + Knowledge Base search + Semantic search + Geoqueries + Entity inspection + API/query generation.

It is therefore less a conventional end-user map and more a developer-oriented visual interface to the Snap4City Knowledge Base, particularly useful for discovering what data exists, where it is located, how entities are related, and how to reference those entities from other Snap4City tools. (Snap4City)

Dashboard Builder can be accessed by using the following link for Florence service map. A platform may have one or more service maps all accessible via the super servicemap as:

https://www.snap4city.org/dashboardSmartCity/management/iframeApp.php?linkUrl=https%3A%2F%2Fwww.snap4city.org%2FMultiServiceMap%2F&pageTitle=SuperServiceMap&linkId=ssmsumer&fromSubmenu=kmlink

  • Share