El dato tiene que entrar donde ya trabajas

Este es el evento que recibe tu sistema cuando un equipo cambia de posición. Lo importante no es la coordenada: es que viene acompañada de su calidad, para que quien la consume pueda decidir cuánto se fía.

{
  "event": "position.updated",
  "timestamp": "2026-03-11T09:41:07Z",
  "terminal": {
    "id": "TRM-0043",
    "team": "vigilancia-l2-turno-manana"
  },
  "position": {
    "zone": "station-014",
    "area": "platform",
    "direction": "north",
    "x": 128.4,
    "y": 22.7,
    "srs": "site-local"
  },
  "onboard": {
    "train": "4207",
    "car": 3
  },
  "quality": {
    "accuracy_m": 6.8,
    "source": "wifi-rtt",
    "nlos_suspected": false,
    "map_matched": true
  }
}

• zone y area son la lectura operativa: estación y recinto. Suele ser lo único que necesita el gestor de incidencias.
• x e y son coordenadas en el sistema local del emplazamiento, para pintar sobre el plano.
• accuracy_m es el radio de incertidumbre estimado de esa lectura concreta, no una constante del sistema.
• onboard aparece solo cuando el agente va en un tren y la capa a bordo está desplegada. Es una identificación exacta, no una estimación: si el objeto no está, es que no se está leyendo ninguna baliza de coche.
• nlos_suspected avisa de que la medida pudo llegar rebotada.
• map_matched indica si la posición se ha ajustado al plano transitable.

• Contratos de datos versionados: los cambios de esquema se anuncian y conviven, no rompen tu integración un martes.
• Retención configurable por tipo de dato, según la política del operador.
• Anonimización y seudonimización aplicables en los flujos que no necesitan identificar a la persona.
• Portabilidad: el histórico se exporta completo cuando se pida. El dato es del operador.