PointOfInterest (JSON)

This example demonstrates how to transform a JSON array containing Milan’s economic activities and points of interest into FIWARE-compliant NGSI-LD entities. It shows how to work with messy, denormalized JSON data with generic field names.

Source Data

The source data is a JSON array where each object represents a business or economic activity with generic field names (FIELD1–FIELD20):

  • FIELD13 — Business name/signage

  • FIELD3, FIELD4, FIELD5, FIELD6 — Street type, name, number, additional info

  • FIELD20 — Sales surface area (square meters)

  • FIELD14–FIELD19 — Sector and classification fields

Mapping Challenges

Generic Field Names

Map generic fields to meaningful attributes based on data documentation:

name: {
    source: "{{ FIELD13 }}",
    type: "Property",
    transformation: "string",
}

Denormalized Address

Concatenate address components with proper spacing:

streetAddress: {
    source: "{{ FIELD3 }} {{ FIELD4 }}, {{ FIELD5 }}{{ FIELD6 }}",
    type: "Property",
    transformation: "string",
}

Complex Description

Build a description from multiple data points:

description: {
    source: "{{ FIELD13 }} ({{ FIELD20 }}sq) - {{ FIELD14 }}, {{ FIELD15 }}, {{ FIELD16 }}, {{ FIELD17 }}, {{ FIELD18 }}, {{ FIELD19 }}",
    type: "Property",
    transformation: "string",
}

Static Entity Identity

All entities use the same static identifier; the system auto-increments (ds49-1, ds49-2, ds49-3…​):

identity: {
    entityName: "ds49",
}

Running the Example

cassiopeia map json -i data/json/PointOfInterest.json -o output -m data/json/PointOfInterest.json5

Key Takeaways

  • Map generic field names to meaningful attributes using documentation

  • Combine multiple fields for address and description construction

  • Use static identity with auto-increment when source lacks unique IDs

  • Handle empty or missing fields with default values

  • Include source attribution for transparency