From 71fc99de4aed8aa35bd0b6b04a62edab33416775 Mon Sep 17 00:00:00 2001 From: isabelle-dr Date: Thu, 9 May 2024 20:03:14 +0200 Subject: [PATCH] Remove spanish translations from GTFS Realtime (#446) * Update README.md * Delete gtfs-realtime/spec/es directory * Update README.md * Update README.md * Update README.md --- gtfs-realtime/README.md | 4 +- gtfs-realtime/spec/es/README.md | 49 -- gtfs-realtime/spec/es/examples/README.md | 4 - gtfs-realtime/spec/es/examples/alerts.asciipb | 72 --- .../es/examples/trip-updates-full.asciipb | 79 --- gtfs-realtime/spec/es/feed-types.md | 36 -- gtfs-realtime/spec/es/gtfs-realtime.proto | 569 ------------------ gtfs-realtime/spec/es/reference.md | 361 ----------- gtfs-realtime/spec/es/service-alerts.md | 56 -- gtfs-realtime/spec/es/trip-updates.md | 56 -- gtfs-realtime/spec/es/vehicle-positions.md | 59 -- 11 files changed, 1 insertion(+), 1344 deletions(-) delete mode 100644 gtfs-realtime/spec/es/README.md delete mode 100644 gtfs-realtime/spec/es/examples/README.md delete mode 100644 gtfs-realtime/spec/es/examples/alerts.asciipb delete mode 100644 gtfs-realtime/spec/es/examples/trip-updates-full.asciipb delete mode 100644 gtfs-realtime/spec/es/feed-types.md delete mode 100644 gtfs-realtime/spec/es/gtfs-realtime.proto delete mode 100644 gtfs-realtime/spec/es/reference.md delete mode 100644 gtfs-realtime/spec/es/service-alerts.md delete mode 100644 gtfs-realtime/spec/es/trip-updates.md delete mode 100644 gtfs-realtime/spec/es/vehicle-positions.md diff --git a/gtfs-realtime/README.md b/gtfs-realtime/README.md index 30322fd0b..8108782c2 100644 --- a/gtfs-realtime/README.md +++ b/gtfs-realtime/README.md @@ -2,8 +2,6 @@ This directory contains GTFS Realtime Specification and documentation. ### Quick links - [GTFS Realtime protocol buffer definition](proto/gtfs-realtime.proto) -- Documentation - - [English](spec/en) - - [Español](spec/es) +- [Spec Realtime Reference](spec/en/reference.md) - [How to change the specification?](CHANGES.md) diff --git a/gtfs-realtime/spec/es/README.md b/gtfs-realtime/spec/es/README.md deleted file mode 100644 index 92fffcd67..000000000 --- a/gtfs-realtime/spec/es/README.md +++ /dev/null @@ -1,49 +0,0 @@ -GTFS en tiempo real es una especificación de feed que permite que las empresas de tranporte público proporcionen actualizaciones en tiempo real sobre su flota a los programadores de la aplicación. Es una extensión de [GTFS](https://developers.google.com/transit/gtfs/reference) (Especificación general de feeds de transporte público), un formato de datos abierto para los horarios de transporte público y la información geográfica asociada. GTFS en tiempo real fue diseñado en torno a la facilidad de implementación, buena interoperabilidad GTFS y un enfoque en la información al pasajero. - -La especificación fue diseñada a través de la asociación de las empresas que eran inicialmente miembros de [Actualizaciones del transporte público en tiempo real](https://developers.google.com/transit/google-transit#LiveTransitUpdates), diferentes programadores de transporte público y Google. La especificación está publicada bajo la licencia [Apache 2.0](http://www.apache.org/licenses/LICENSE-2.0). - -## ¿Cómo empiezo? - -1. Sigue leyendo el resumen general. -2. Decide qué [tipos de feed](feed-types.md) proporcionarás. -3. Consulta los [ejemplos de feeds](examples/). -4. Crea tus propios feeds mediante la [referencia](reference.md). -5. Publica tu feed. - -## Resumen general de los tipos de feed GTFS en tiempo real - -La especificación es compatible actualmente con los siguientes tipos de información: - -* **Actualizaciones de viaje**: retrasos, cancelaciones, cambios de ruta -* **Alertas del servicio**: traslados de paradas o eventos imprevistos que afectan una estación, ruta o toda la red -* **Posiciones del vehículo**: información sobre los vehículos, incluidos la ubicación y el nivel de congestión - -Las actualizaciones de cada tipo se proporcionan en un feed separado. Los feeds se muestran a través de HTTP y se actualizan con frecuencia. El archivo en sí es un archivo binario normal, por lo que cualquier tipo de servidor web puede alojar y mostrar el archivo (es posible utilizar otros protocolos de transferencia también). También se podrían utilizar servidores de aplicaciones web, los cuales devolverían el feed como una respuesta a una solicitud GET de HTTP válida. No hay limitaciones en cuanto a la frecuencia ni a los métodos exactos con los que el feed debe ser actualizado o recuperado. - -Ya que GTFS en tiempo real te permite presentar el estado _real_ de tu flota, el feed debe ser actualizado con frecuencia, preferentemente cuando se reciban nuevos datos del sistema de ubicación automática de vehículos. - -[Más información sobre los tipos de feed...](feed-types.md) - -## Formato de los datos - -El formato de intercambio de datos de GTFS en tiempo real se basa en [Búferes de protocolo](https://developers.google.com/protocol-buffers/). - -Los búferes de protocolo son un mecanismo de lenguaje y plataforma neutral para serializar datos estructurados (como XML, pero más pequeño, rápido y simple). La estructura de datos se define en un archivo [gtfs-realtime.proto](gtfs-realtime.proto), que luego se utiliza para generar el código fuente para leer y escribir fácilmente tus datos estructurados desde y hacia una variedad de flujos de datos, mediante diferentes lenguajes, por ejemplo Java, C++ o Python. - -[Más información sobre los búferes de protocolo](https://developers.google.com/protocol-buffers/)... - -## Estructura de los datos - -La jerarquía de los elementos y las definiciones de su tipo están especificadas en el archivo [gtfs-realtime.proto](gtfs-realtime.proto). - -Este archivo de texto se utiliza para generar las bibliotecas necesarias en el lenguaje de programación que se elija. Estas bibliotecas proporcionan las clases y funciones necesarias para generar feeds GTFS en tiempo real válidos. Las bibliotecas no solo hacen que la creación del feed sea más fácil, sino que también garantizan que solo se produzcan feeds válidos. - -[Más información sobre la estructura de los datos.](reference.md) - -## Obtener ayuda - -Para participar en los debates sobre GTFS en tiempo real y sugerir cambios y adiciones a la especificación, únete al [grupo de debate de GTFS en tiempo real](http://groups.google.com/group/gtfs-realtime). - -## Google Maps y Actualizaciones de transporte público en tiempo real - -Una de las posibles aplicaciones que utiliza GTFS en tiempo real es [Actualizaciones de transporte público en tiempo real](https://developers.google.com/transit/google-transit#LiveTransitUpdates), una función de Google Maps que proporciona a los usuarios información de transporte público en tiempo real. Si trabajas para una empresa de transporte público que está interesada en proporcionar actualizaciones en tiempo real para Google Maps, visita la [Página de socios de Google Transit](http://maps.google.com/help/maps/transit/partners/live-updates.html). diff --git a/gtfs-realtime/spec/es/examples/README.md b/gtfs-realtime/spec/es/examples/README.md deleted file mode 100644 index 50d3ed119..000000000 --- a/gtfs-realtime/spec/es/examples/README.md +++ /dev/null @@ -1,4 +0,0 @@ -Los siguientes ejemplos muestran una representación textual de los feeds. Durante el desarrollo, es conveniente producir búferes de protocolo en formato ASCII para que la depuración resulte más sencilla. Puedes comparar tus archivos de texto resultantes con estos ejemplos para comprobar la validez de los datos: - -* [Alertas de Google](alerts.asciipb) -* [Actualización de viaje (conjunto de datos completo)](trip-updates-full.asciipb) diff --git a/gtfs-realtime/spec/es/examples/alerts.asciipb b/gtfs-realtime/spec/es/examples/alerts.asciipb deleted file mode 100644 index 663c405db..000000000 --- a/gtfs-realtime/spec/es/examples/alerts.asciipb +++ /dev/null @@ -1,72 +0,0 @@ -# Información del encabezado -header { - # Versión de la especificación de velocidad. Actualmente "1.0". - gtfs_realtime_version: "1.0" - - # Determina si el conjunto de datos se completó o tiene un incremento gradual. - incrementality: FULL_DATASET - - # La hora en la que se generó el conjunto de datos en el servidor - # para determinar la secuencia de feeds de alerta. - timestamp: 1284457468 -} -# Se pueden incluir varias entidades en el feed. -entity { - # Identificador único para la entidad - id: "0" - - # "Tipo" de la entidad - alert { - # Se pueden definir varios períodos cuando la alerta está activa. - active_period { - # Hora de inicio en formato epoch POSIX - start: 1284457468 - # Hora de fin en formato epoch POSIX - end: 1284468072 - } - # Selecciona qué entidades GTFS serán afectadas. - informed_entity { - # Parámetros válidos: agency_id, route_id, route_type, - # stop_id, viaje (consultar TripDescriptor) - route_id: "219" - } - # Se pueden entregar selectores múltiples (informed_entity). - informed_entity { - stop_id: "16230" - } - - # Causa de la alerta: consultar gtfs-realtime.proto para valores válidos - cause: CONSTRUCTION - # Efecto de la alerta: consultar gtfs-realtime.proto para valores reales - effect: DETOUR - - # La URL dada proporciona información adicional. - url { - # Varios idiomas/traducciones compatibles - translation { - # La página está alojada fuera de Google (en el proveedor o la empresa, etc.). - text: "http://www.sometransitagency/alerts" - language: "es" - } - } - - # El encabezado para la alerta será destacado. - header_text { - # Varios idiomas o traducciones son compatibles. - translation { - text: "La parada en Elm street está cerrada, detenerse temporalmente en Oak street" - language: "es" - } - } - - # Descripción de la alerta. Información adicional al texto del encabezado. - description_text { - # Varios idiomas o traducciones son compatibles. - translation { - text: "Debido a una construcción en Elm street, la parada está cerrada. La parada temporal se puede encontrar a 300 metros al norte de Oak street." - language: "es" - } - } - } -} - diff --git a/gtfs-realtime/spec/es/examples/trip-updates-full.asciipb b/gtfs-realtime/spec/es/examples/trip-updates-full.asciipb deleted file mode 100644 index f8e653964..000000000 --- a/gtfs-realtime/spec/es/examples/trip-updates-full.asciipb +++ /dev/null @@ -1,79 +0,0 @@ -# Información del encabezado -header { - # Especificación de la versión de la velocidad. La versión "1.0" actual - gtfs_realtime_version: "1.0" - # determina si el conjunto de datos se completó o continúa creciendo - incrementality: FULL_DATASET - # en el momento en el que se generó en el servidor. - timestamp: 1284457468 -} - -# Se pueden incluir varias entidades en el -entity { - # identificador único del feed correspondiente a la entidad - id: "simple-trip" - - # "tipo" de la entidad. - trip_update { - trip { - # Selecciona qué entidad GTFS (viaje) se verá afectada. - trip_id: "trip-1" - } - # Actualización de la información del programa - stop_time_update { - # Se selecciona qué parada se ve afectada - stop_sequence: 3 - # para que el vehículo llegue - arrival { - # cinco segundos tarde. - delay: 5 - } - } - # La demora de este vehículo se extiende a las siguientes paradas. - - # Próxima actualización de la información acerca del programa del vehículo - stop_time_update { - # según el campo stop_sequence. Se actualizará - stop_sequence: 8 - # el horario de llegada original del vehículo (programado) con una - arrival { - # demora de un segundo. - delay: 1 - } - } - # ...Asimismo, la demora se extiende a las siguientes paradas. - - # Próxima actualización de la información acerca del programa del vehículo - stop_time_update { - # según el campo stop_sequence. Se actualizará el horario de llegada del vehículo - stop_sequence: 10 - # con la demora predeterminada de cero segundos (a tiempo) y se extenderá esta actualización - # al resto de las paradas del vehículo. - } - } -} - -# Segunda entidad con información acerca de la actualización de otro viaje -entity { - id: "3" - trip_update { - trip { - # En función de su frecuencia, los viajes se definen según el - # trip_id de la especificación GTFS y el campo - trip_id: "frequency-expanded-trip" - # start_time - start_time: "11:15:35" - } - stop_time_update { - stop_sequence: 1 - arrival { - # Una demora negativa se produce cuando el vehículo se adelanta dos segundos según lo establecido en el programa. - delay: -2 - } - } - stop_time_update { - stop_sequence: 9 - } - } -} - diff --git a/gtfs-realtime/spec/es/feed-types.md b/gtfs-realtime/spec/es/feed-types.md deleted file mode 100644 index 07636f2aa..000000000 --- a/gtfs-realtime/spec/es/feed-types.md +++ /dev/null @@ -1,36 +0,0 @@ -La especificación GTFS en tiempo real admite el envío de tres tipos diferentes de datos en tiempo real. Si bien la sintaxis del archivo [gtfs-realtime.proto](gtfs-realtime.proto) permite que se mezclen distintos tipos de entidades para un único feed, solo se puede usar un tipo de entidad por feed. Puedes encontrar resúmenes más abajo, teniendo la documentación completa en la sección correspondiente. - -## Actualizaciones de viaje - -#### "El autobús X tiene una demora de cinco minutos". - -Las actualizaciones de viaje ofrecen información acerca de fluctuaciones en el horario. Esperamos recibir actualizaciones de viaje de todos los viajes programados cuya duración se puede predecir en tiempo real. Estas actualizaciones ofrecerían un horario de llegada o salida para las diferentes paradas de la ruta. Las actualizaciones de viaje también pueden brindar información en situaciones más complejas, como cuando los viajes se cancelan o agregan al programa, o como cuando su trayecto se modifica. - -[Más información acerca de las Actualizaciones de viaje...](trip-updates.md) - -## Alertas de servicio - -#### "La estación Y está cerrada por tareas de construcción". - -Las alertas de servicio ofrecen información acerca de problemas más graves que puede sufrir una entidad en particular. En general, se expresan a través de una descripción textual de la interrupción. - -Pueden representar los problemas que sufren: - -* las estaciones, -* las líneas, -* la red completa, -* etc. - -Una alerta de servicio a menudo consiste en una descripción textual del problema. También permitimos que se incluyan las URL de los sitios en los que se ofrecen más detalles e información más estructurada para poder entender a quién afecta una alerta de servicio. - -[Más información acerca de las Alertas de servicio...](service-alerts.md) - -## Posiciones de los vehículos - -#### "Este autobús se encuentra en la posición X a la hora Y". - -La posición de un vehículo ofrece datos básicos acerca de un vehículo en particular de la red. - -La información más importante consiste en la latitud y longitud donde se encuentra el vehículo. Sin embargo, también podemos usar las lecturas de cuentakilómetros y velocidad actuales del vehículo. - -[Más información acerca las actualizaciones de las Posiciones de los vehículos...](vehicle-positions.md) diff --git a/gtfs-realtime/spec/es/gtfs-realtime.proto b/gtfs-realtime/spec/es/gtfs-realtime.proto deleted file mode 100644 index e8c84d420..000000000 --- a/gtfs-realtime/spec/es/gtfs-realtime.proto +++ /dev/null @@ -1,569 +0,0 @@ -// Copyright 2015 The GTFS Specifications Authors. -// -// Licensed under the Apache License, Version 2.0 (the "License"); -// you may not use this file except in compliance with the License. -// You may obtain a copy of the License at -// -// http://www.apache.org/licenses/LICENSE-2.0 -// -// Unless required by applicable law or agreed to in writing, software -// distributed under the License is distributed on an "AS IS" BASIS, -// WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. -// See the License for the specific language governing permissions and -// limitations under the License. - -// Archivo de definición de protocolo para GTFS en tiempo real. -// -// GTFS en tiempo real permite que las agencias de transporte público brinden a -// los consumidores información en tiempo real acerca de las interrupciones de -// sus servicios (estaciones cerradas, líneas que no funcionan, demoras -// importantes, etc.), la ubicación de sus vehículos y los horarios de llegada -// esperados. -// -// Este protocolo se publica en: -// https://github.com/google/transit/tree/master/gtfs-realtime - -syntax = "proto2"; - -option java_package = "com.google.transit.realtime"; -package transit_realtime; - -// El contenido de un mensaje de feed -// Un feed es un flujo continuo de mensajes de feed. Cada mensaje del flujo se -// obtiene como una respuesta a una solicitud HTTP GET adecuada. -// Un feed en tiempo real siempre se define con relación a un feed GTFS -// existente. Todos los ID de entidad se resuelven con respecto al feed GTFS. -// -// Un feed depende de cierta configuración externa: -// - El feed GTFS correspondiente. -// - Aplicación del feed (actualizaciones, posiciones o alertas). Un feed solo -// debe contener elementos de una aplicación especificada; todas las demás -// entidades se ignorarán. -// - Frecuencia de sondeo. -message FeedMessage { - // Metadatos acerca de este feed y mensaje de feed - required FeedHeader header = 1; - - // Contenido del feed - repeated FeedEntity entity = 2; -} - -// Metadatos acerca de un feed, incluidos en mensajes de feed -message FeedHeader { - // Versión de la especificación de feed - // La versión actual es 1.0. - required string gtfs_realtime_version = 1; - - // Determina si la búsqueda actual es incremental. Actualmente, el modo - // DIFFERENTIAL no es admitido y no se especifica para feeds que usan este - // modo. Existen foros de debate en la lista de correo de GTFS en tiempo real - // sobre la especificación completa del comportamiento del modo DIFFERENTIAL y - // la documentación se actualizará cuando esos foros de debate finalicen. - enum Incrementality { - FULL_DATASET = 0; - DIFFERENTIAL = 1; - } - optional Incrementality incrementality = 2 [default = FULL_DATASET]; - - // Esta marca de tiempo identifica el momento en que se creó el contenido de - // este feed (en tiempo del servidor). En tiempo POSIX (es decir, la cantidad - // de segundos desde el 1.º de enero de 1970 00:00:00 UTC). - optional uint64 timestamp = 3; - - // El espacio de nombres de extensiones permite a los programadores externos - // extender la especificación de GTFS en tiempo real para agregar y evaluar - // nuevas funciones y modificaciones a la especificación. - extensions 1000 to 1999; -} - -// Una definición (o actualización) de una entidad en el feed de transporte -// público. -message FeedEntity { - // Los ID se usan solo para proporcionar asistencia sobre el aumento - // incremental. El ID debe ser único dentro de un FeedMessage. Los - // FeedMessages consiguientes pueden contener FeedEntities con el mismo ID. En - // el caso de una actualización DIFFERENTIAL, la nueva FeedEntity con algunos - // ID reemplazará a la antigua FeedEntity con el mismo ID (o la eliminará: - // consulta is_deleted a continuación). Las entidades de GTFS reales (p. ej., - // estaciones, rutas, viajes) a las que hace referencia el feed deben estar - // especificadas por selectores explícitos (consulta EntitySelector a - // continuación para obtener más información). - required string id = 1; - - // Establece si esta entidad debe eliminarse. Relevante solo para búsquedas - // incrementales. - optional bool is_deleted = 2 [default = false]; - - // Datos acerca de la propia entidad. Exactamente uno de los siguientes campos - // debe estar presente (a menos que se esté eliminando la entidad). - optional TripUpdate trip_update = 3; - optional VehiclePosition vehicle = 4; - optional Alert alert = 5; -} - -// -// Entidades usadas en el feed. -// - -// La actualización en tiempo real del progreso de un vehículo a lo largo de un -// viaje. Dependiendo del valor de ScheduleRelationship, un TripUpdate puede -// especificar: -// - Un viaje que continúa según el programa. -// - Un viaje que continúa por la ruta, pero no tiene un programa fijo. -// - Un viaje que se agregó o eliminó con respecto al programa. -// -// Las actualizaciones pueden ser para eventos de llegada/salida futuros -// previstos o para eventos pasados que ya ocurrieron. -// Normalmente, las actualizaciones deben ser más precisas y más certeras -// (consulta incertidumbre a continuación) a medida que los eventos se acercan -// al momento actual. -// Aun cuando eso no sea posible, la información para eventos pasados debe ser -// precisa y certera. En particular, si una actualización apunta a un momento -// pasado, pero la incertidumbre de su actualización no es 0, el cliente debe -// concluir que la actualización es una predicción (errónea) y que el viaje aún -// no se ha completado. -// -// Ten en cuenta que la actualización puede describir un viaje que ya se ha -// completado. A este fin, proporcionar una actualización para la última parada -// del viaje es suficiente. Si tal momento está en el pasado, el cliente -// concluirá que todo el viaje está en el pasado (es posible, aunque ilógico, -// proporcionar también actualizaciones para las paradas precedentes). Esta -// opción es más relevante para un viaje que se ha completado con anticipación a -// lo programado, pero que, de acuerdo con el programa, el viaje todavía -// continúa en este momento. Si se eliminan las actualizaciones para este viaje, -// el cliente puede asumir que el viaje todavía continúa. Ten en cuenta que al -// proveedor del feed se le permite, pero no está obligado a, purgar -// actualizaciones pasadas: en este caso, esto sería útil en la práctica. -message TripUpdate { - // El viaje al que se aplica este mensaje. Puede haber como máximo una - // entidad TripUpdate para cada instancia de viaje real. - // Si no hay ninguna, eso significa que no hay información de predicción - // disponible. *No* significa que el viaje se está realizando de acuerdo con - // la programación. - required TripDescriptor trip = 1; - - // Información adicional sobre el vehículo que está realizando el viaje. - optional VehicleDescriptor vehicle = 3; - - // Información sobre los tiempos para un solo evento previsto (ya sea llegada - // o salida). - // Los horarios consisten en la información sobre demoras o tiempos estimados - // y la incertidumbre. La demora (delay) debe usarse cuando la predicción se - // realiza con relación a una programación existente en GTFS. - // - El tiempo (time) debe darse aunque no haya una programación prevista. Si - // se especifican tanto el tiempo como la demora, el tiempo será prioritario - // (aunque, por lo general, el tiempo, si se otorga para un viaje - // programado, debe ser igual al tiempo programado en GTFS + la demora). - // - // La incertidumbre se aplica de la misma forma tanto al tiempo como a la - // demora. La incertidumbre especifica el error esperado en una demora real - // (pero ten en cuenta, que todavía no definimos su significado estadístico - // concreto). Es posible que la incertidumbre sea 0, por ejemplo, para los - // trenes que funcionan con un control de horarios por computadora. - message StopTimeEvent { - // La demora (en segundos) puede ser positiva (significa que el vehículo - // está retrasado) o negativa (significa que el vehículo está adelantado). - // Una demora de 0 significa que el vehículo está yendo a tiempo. - optional int32 delay = 1; - - // El evento como tiempo absoluto - // En tiempo Unix (es decir, la cantidad de segundos desde el 1.º de enero - // de 1970 00:00:00 UTC). - optional int64 time = 2; - - // Si se omite la incertidumbre, se interpreta como desconocida. - // Si la predicción es desconocida o demasiado incierta, el campo demora (o - // tiempo) debe estar vacío. En tal caso, el campo incertidumbre se ignora. - // Para especificar una predicción completamente cierta, configura su - // incertidumbre en 0. - optional int32 uncertainty = 3; - - // El espacio de nombres de extensiones permite a los programadores externos - // extender la especificación de GTFS en tiempo real para agregar y evaluar - // nuevas funciones y modificaciones a la especificación. - extensions 1000 to 1999; - } - - // Actualización en tiempo real para eventos de llegada o salida para una - // determinada parada en un viaje. Se pueden suministrar actualizaciones tanto - // para eventos pasados como para eventos futuros. Al productor se le - // permite, aunque no está obligado a, proporcionar eventos pasados. - message StopTimeUpdate { - // La actualización está vinculada con una parada específica ya sea mediante - // stop_sequence o stop_id, de manera que necesariamente debe configurarse - // uno de los campos que aparecen a continuación. Consulta la documentación - // en TripDescriptor para obtener más información. - - // Debe ser la misma que la de stop_times.txt en el feed GTFS - // correspondiente. - optional uint32 stop_sequence = 1; - // Debe ser el mismo que el de stops.txt en el feed GTFS correspondiente. - optional string stop_id = 4; - - optional StopTimeEvent arrival = 2; - optional StopTimeEvent departure = 3; - - // La relación entre este StopTime y el programa estático. - enum ScheduleRelationship { - // El vehículo continúa conforme a su programa estático de paradas, aunque - // no necesariamente de acuerdo a los horarios del programa. - // Se debe proporcionar al menos uno de los horarios de llegada y salida. - // Si el programa para esta parada contiene los horarios tanto de llegada - // como de salida, entonces esta actualización también debe tenerlos. Una - // actualización con solo una llegada, por ejemplo, cuando el programa - // tiene ambos, indica que el viaje está terminando temprano en esta - // parada. - SCHEDULED = 0; - - // La parada se omite, es decir, el vehículo no se detendrá en esta - // parada. La llegada y la salida son opcionales. - SKIPPED = 1; - - // No hay datos para esta parada. La intención principal de este valor es - // brindar predicciones solo para parte de un viaje, es decir, si la - // última actualización para un viaje tiene un especificador NO_DATA, - // entonces se considerará que tampoco se especifican StopTimes para el - // resto de las paradas del viaje. No se debe suministrar ni la llegada - // ni la salida. - NO_DATA = 2; - } - optional ScheduleRelationship schedule_relationship = 5 - [default = SCHEDULED]; - - // El espacio de nombres de extensiones permite a los programadores externos - // extender la especificación de GTFS en tiempo real para agregar y evaluar - // nuevas funciones y modificaciones a la especificación. - extensions 1000 to 1999; - } - - // Actualizaciones a StopTimes para el viaje (tanto futuras, es decir, - // predicciones, como, en algunos casos, pasadas, es decir, aquellas que ya - // ocurrieron). - // Las actualizaciones se deben clasificar por stop_sequence y aplicarse a - // todas las paradas siguientes del viaje hasta la próxima especificada. - // - // Ejemplo 1: - // Para un viaje con 20 paradas, una StopTimeUpdate con demora de llegada y - // demora de salida de 0 para una stop_sequence de la parada actual significa - // que el viaje está llegando exactamente a horario. - // - // Ejemplo 2: - // Para la misma instancia de viaje, se proporcionan 3 StopTimeUpdates: - // - demora de 5 minutos para la stop_sequence 3 - // - demora de 1 minuto para la stop_sequence 8 - // - demora de duración no especificada para la stop_sequence 10 - // Esto se interpretará como: - // - las stop_sequences 3,4,5,6,7 tienen una demora de 5 minutos. - // - las stop_sequences 8,9 tienen una demora de 1 minuto. - // - las stop_sequences 10,... tienen una demora desconocido. - repeated StopTimeUpdate stop_time_update = 2; - - // Momento en el cual se midió el progreso en tiempo real del vehículo. En - // tiempo POSIX (es decir, la cantidad de segundos desde el 1º de enero de - // 1970 00:00:00 UTC). - optional uint64 timestamp = 4; - - // El espacio de nombres de extensiones permite a los programadores externos - // extender la especificación de GTFS en tiempo real para agregar y evaluar - // nuevas funciones y modificaciones a la especificación. - extensions 1000 to 1999; -} - -// Información de posicionamiento en tiempo real de un vehículo dado. -message VehiclePosition { - // El viaje que este vehículo está realizando. - // Puede estar vacío o ser parcial si el vehículo no se puede identificar con - // una instancia de viaje dada. - optional TripDescriptor trip = 1; - - // Información adicional sobre el vehículo que está realizando este viaje. - optional VehicleDescriptor vehicle = 8; - - // Posición actual de este vehículo. - optional Position position = 2; - - // El índice de la secuencia de parada de la parada actual. El significado de - // current_stop_sequence (es decir, la parada a la que hace referencia) lo - // determina current_status. - // Si falta current_status, se asume IN_TRANSIT_TO. - optional uint32 current_stop_sequence = 3; - // Identifica la parada actual. El valor debe ser el mismo que el de stops.txt - // en el feed GTFS correspondiente. - optional string stop_id = 7; - - enum VehicleStopStatus { - // El vehículo está a punto de llegar a la parada (en una visualización de - // la parada, el símbolo del vehículo, por lo general, parpadea). - INCOMING_AT = 0; - - // El vehículo está detenido en la parada. - STOPPED_AT = 1; - - // El vehículo ha partido y está en tránsito hacia la siguiente parada. - IN_TRANSIT_TO = 2; - } - // El estado exacto del vehículo con respecto a la parada actual. - // Se ignora si falta el valor en current_stop_sequence. - optional VehicleStopStatus current_status = 4 [default = IN_TRANSIT_TO]; - - // Momento en el cual se midió la posición del vehículo. En tiempo POSIX (es - // decir, la cantidad de segundos desde el 1º de enero de 1970 00:00:00 UTC). - optional uint64 timestamp = 5; - - // El nivel de congestión que está afectando a este vehículo. - enum CongestionLevel { - UNKNOWN_CONGESTION_LEVEL = 0; - RUNNING_SMOOTHLY = 1; - STOP_AND_GO = 2; - CONGESTION = 3; - SEVERE_CONGESTION = 4; // Personas que dejan sus autos. - } - optional CongestionLevel congestion_level = 6; - - // El espacio de nombres de extensiones permite a los programadores externos - // extender la especificación de GTFS en tiempo real para agregar y evaluar - // nuevas funciones y modificaciones a la especificación. - extensions 1000 to 1999; -} - -// Una alerta, que indica que existe algún tipo de incidente en la red de -// transporte público. -message Alert { - // Tiempo durante el cual la alerta debe mostrarse al usuario. Si falta, la - // alerta se mostrará durante todo el tiempo en que aparezca en el feed. - // Si se proporcionan múltiples intervalos, la alerta se mostrará durante - // todos ellos. - repeated TimeRange active_period = 1; - - // Entidades a cuyos usuarios debemos notificar esta alerta. - repeated EntitySelector informed_entity = 5; - - // Causa de esta alerta. - enum Cause { - UNKNOWN_CAUSE = 1; - OTHER_CAUSE = 2; // No representable mediante máquina. - TECHNICAL_PROBLEM = 3; - STRIKE = 4; // Los empleados de las empresas de transporte público dejaron de trabajar. - DEMONSTRATION = 5; // Las personas están bloqueando las calles. - ACCIDENT = 6; - HOLIDAY = 7; - WEATHER = 8; - MAINTENANCE = 9; - CONSTRUCTION = 10; - POLICE_ACTIVITY = 11; - MEDICAL_EMERGENCY = 12; - } - optional Cause cause = 6 [default = UNKNOWN_CAUSE]; - - // El efecto de este problema en la entidad afectada. - enum Effect { - NO_SERVICE = 1; - REDUCED_SERVICE = 2; - - // No nos preocupan las demoras NO significativas: son difíciles de - // detectar, tienen un pequeño impacto sobre el usuario y desordenarían los - // resultados ya que son demasiado frecuentes. - SIGNIFICANT_DELAYS = 3; - - DETOUR = 4; - ADDITIONAL_SERVICE = 5; - MODIFIED_SERVICE = 6; - OTHER_EFFECT = 7; - UNKNOWN_EFFECT = 8; - STOP_MOVED = 9; - } - optional Effect effect = 7 [default = UNKNOWN_EFFECT]; - - // La URL que proporciona información adicional acerca de la alerta. - optional TranslatedString url = 8; - - // Encabezado de la alerta. Contiene un breve resumen del texto de la alerta - // como texto simple. - optional TranslatedString header_text = 10; - - // Descripción completa de la alerta como texto simple. La información de la - // descripción debe agregar a la información del encabezado. - optional TranslatedString description_text = 11; - - // El espacio de nombres de extensiones permite a los programadores externos - // extender la especificación de GTFS en tiempo real para agregar y evaluar - // nuevas funciones y modificaciones a la especificación. - extensions 1000 to 1999; -} - -// -// Estructuras de datos de bajo nivel que se utilizaron más arriba. -// - -// Un intervalo de tiempo. El intervalo se considera activo a la hora 't' si 't' -// es mayor o igual que la hora de inicio y menor que la hora de finalización. -message TimeRange { - // Hora de inicio, en tiempo POSIX (es decir, la cantidad de segundos desde el - // 1º de enero de 1970 00:00:00 UTC). - // Si falta esta información, el intervalo comienza en el infinito negativo. - optional uint64 start = 1; - - // Hora de finalización, en tiempo POSIX (es decir, la cantidad de segundos - // desde el 1º de enero de 1970 00:00:00 UTC). - // Si falta esta información, el intervalo finaliza en el infinito positivo. - optional uint64 end = 2; -} - -// Una posición. -message Position { - // Grados al Norte, en el sistema de coordenadas WGS-84. - required float latitude = 1; - - // Grados al Este, en el sistema de coordenadas WGS-84 - required float longitude = 2; - - // Orientación, en grados, en el sentido de las agujas del reloj desde el - // Norte, es decir, 0 es Norte y 90 es Este. Esto puede ser la orientación de - // la brújula o la dirección hacia la siguiente parada o la ubicación - // intermedia. - // Esto no debe deducirse de las instrucciones de la secuencia de posiciones - // anteriores, que puede calcularse a partir de los datos anteriores. - optional float bearing = 3; - - // Valor del odómetro, en metros. - optional double odometer = 4; - // Velocidad momentánea medida por el vehículo, en metros por segundo. - optional float speed = 5; - - // El espacio de nombres de extensiones permite a los programadores externos - // extender la especificación de GTFS en tiempo real para agregar y evaluar - // nuevas funciones y modificaciones a la especificación. - extensions 1000 to 1999; -} - -// Un descriptor que identifica una instancia de un viaje de GTFS, o todas las -// instancias de un viaje por una ruta. -// - Para especificar una sola instancia de viaje, se establece el trip_id (y, -// en caso de ser necesario, el start_time). Si también se establece el -// route_id, entonces debe ser el mismo al que corresponde el viaje dado. -// - Para especificar todos los viajes por una ruta dada, solo se debe -// establecer el route_id. Ten en cuenta que si el trip_id no se conoce, -// entonces los identificadores de secuencia de parada en TripUpdate no son -// suficientes y los stop_ids también se deben proporcionar. Además, se deben -// proporcionar las horas absolutas de llegada/salida. -message TripDescriptor { - // El trip_id del feed GTFS al cual hace referencia este selector. - // Para viajes sin frecuencia expandida, este campo es suficiente para - // identificar de forma unívoca al viaje. Para viajes con frecuencia - // expandida, start_time y start_date también podrían ser necesarios. - optional string trip_id = 1; - - // El route_id de GTFS al cual hace referencia este selector. - optional string route_id = 5; - - // La hora de inicio programada de esta instancia de viaje. - // Este campo debe proporcionarse solo si el viaje es de frecuencia expandida - // en el feed GTFS. El valor debe corresponder precisamente a la start_time - // especificada para la ruta del feed GTFS más algún múltiplo de headway_secs. - // El formato del campo es el mismo que el de GTFS/frequencies.txt/start_time, - // p. ej., 11:15:35 o 25:15:35. - optional string start_time = 2; - - // La fecha de inicio programada de esta instancia de viaje. - // Se debe proporcionar para desambiguar los viajes que están tan retrasados - // que pueden colisionar con un viaje programado para el día siguiente. Por - // ejemplo, para un tren que sale a las 8:00 y a las 20:00 todos los días, y - // que tiene una demora de 12 horas, habrá dos viajes diferentes a la misma - // hora. - // Este campo se puede proporcionar pero no es obligatorio para los programas - // en los cuales tales colisiones son imposibles: por ejemplo, un servicio que - // funciona según una programación por hora donde un vehículo que tiene una - // demora de una hora ya deja de considerarse relacionado con el programa. - // En formato AAAAMMDD. - optional string start_date = 3; - - // La relación entre este viaje y el programa estático. Si un viaje se realiza - // de acuerdo con un programa temporal, no se refleja en GTFS, entonces - // no debe marcarse como SCHEDULED, sino como ADDED. - enum ScheduleRelationship { - // Viaje que se está ejecutando de acuerdo con su programa de GTFS,o que es - // lo suficientemente parecido al viaje programado como para asociarse a él. - SCHEDULED = 0; - - // Un viaje adicional que se ha agregado a un programa en ejecución, por - // ejemplo, para reemplazar un vehículo averiado o para responder a una - // carga repentina de un pasajero. - ADDED = 1; - - // Un viaje que se está ejecutando sin ningún programa asociado, por - // ejemplo, cuando no existe ningún programa. - UNSCHEDULED = 2; - - // Un viaje que existió en el programa, pero se eliminó. - CANCELED = 3; - } - optional ScheduleRelationship schedule_relationship = 4; - - // El espacio de nombres de extensiones permite a los programadores externos - // extender la especificación de GTFS en tiempo real para agregar y evaluar - // nuevas funciones y modificaciones a la especificación. - extensions 1000 to 1999; -} - -// Información de identificación para el vehículo que realiza el viaje. -message VehicleDescriptor { - // Identificación interna del sistema para el vehículo. Debe ser única para el - // vehículo y se puede usar para realizar un seguimiento del vehículo a medida - // que avanza en el sistema. - optional string id = 1; - - // Etiqueta visible para el usuario, es decir, algo que se debe mostrar al - // pasajero para ayudarlo a identificar el vehículo correcto. - optional string label = 2; - - // La patente del vehículo. - optional string license_plate = 3; - - // El espacio de nombres de extensiones permite a los programadores externos - // extender la especificación de GTFS en tiempo real para agregar y evaluar - // nuevas funciones y modificaciones a la especificación. - extensions 1000 to 1999; -} - -// Un selector para una entidad en un feed GTFS. -message EntitySelector { - // Los valores de los campos deben corresponder a los campos apropiados en el - // feed GTFS. - // Se debe brindar, al menos, un especificador. Si se proporcionan varios, - // entonces el que coincide debe aplicarse a todos los especificadores dados. - optional string agency_id = 1; - optional string route_id = 2; - // corresponde a route_type en GTFS. - optional int32 route_type = 3; - optional TripDescriptor trip = 4; - optional string stop_id = 5; - - // El espacio de nombres de extensiones permite a los programadores externos - // extender la especificación de GTFS en tiempo real para agregar y evaluar - // nuevas funciones y modificaciones a la especificación. - extensions 1000 to 1999; -} - -// Un mensaje internacionalizado que contiene versiones por idioma de un -// fragmento de texto o una URL. -// Se seleccionará una de las cadenas de un mensaje. La resolución se realiza de -// la siguiente manera: -// 1. Si el idioma de la interfaz de usuario coincide con el código de idioma de -// una traducción, se elige la primera traducción coincidente. -// 2. Si un idioma de interfaz de usuario predeterminado (p. ej., inglés) -// coincide con el código de idioma de una traducción, se elige la primera -// traducción coincidente. -// 3. Si alguna traducción tiene un código de idioma no especificado, se elige -// esa traducción. -message TranslatedString { - message Translation { - // Una cadena UTF-8 que contiene el mensaje. - required string text = 1; - // Código de idioma BCP-47. Se puede omitir si el idioma es desconocido o si - // no se realiza ningún i18n para el feed. Como máximo, se permite que - // una traducción tenga una etiqueta de idioma no especificado. - optional string language = 2; - } - // Se debe proporcionar al menos una traducción. - repeated Translation translation = 1; -} diff --git a/gtfs-realtime/spec/es/reference.md b/gtfs-realtime/spec/es/reference.md deleted file mode 100644 index 6c79f80cf..000000000 --- a/gtfs-realtime/spec/es/reference.md +++ /dev/null @@ -1,361 +0,0 @@ -Un feed GTFS en tiempo real permite que las empresas de transporte público brinden a los consumidores información en tiempo real acerca de las interrupciones de sus servicios (estaciones cerradas, líneas que no funcionan, demoras importantes, etc.), la ubicación de sus vehículos y tiempos de llegada esperados. - -Las especificaciones de la versión 1.0 del feed se abordan y documentan aquí. - -### Definiciones de términos - -* **obligatorio**: uno -* **repetido**: cero o más -* **mensaje**: tipo complejo -* **enum.**: lista de valores fijos -* **experimental**: campo experimental, sujeto a cambios. Podrá ser formalmente adoptado más adelante. - -## Índice de elementos - -* [FeedMessage](#mensaje-feedmessage) - * [FeedHeader](#mensaje-feedheader) - * [Incrementality](#enum-incrementality) - * [FeedEntity](#mensaje-feedentity) - * [TripUpdate](#mensaje-tripupdate) - * [TripDescriptor](#mensaje-tripdescriptor) - * [ScheduleRelationship](#enum-schedulerelationship-1) - * [VehicleDescriptor](#mensaje-vehicledescriptor) - * [StopTimeUpdate](#mensaje-stoptimeupdate) - * [StopTimeEvent](#mensaje-stoptimeevent) - * [ScheduleRelationship](#enum-schedulerelationship) - * [VehiclePosition](#mensaje-vehicleposition) - * [TripDescriptor](#mensaje-tripdescriptor) - * [ScheduleRelationship](#enum-schedulerelationship-1) - * [Position](#mensaje-position) - * [Alert](#mensaje-alert) - * [TimeRange](#mensaje-timerange) - * [EntitySelector](#mensaje-entitySelector) - * [TripDescriptor](#mensaje-tripdescriptor) - * [ScheduleRelationship](#enum-schedulerelationship-1) - * [Cause](#enum-cause) - * [Effect](#enum-effect) - * [TranslatedString](#mensaje-translatedstring) - * [Translation](#mensaje-translation) - -# Elementos - -## _mensaje_ FeedMessage - -El contenido de un mensaje de feed. Cada mensaje en el flujo de datos se obtiene como una respuesta a una solicitud HTTP GET adecuada. Un feed en tiempo real siempre se define en relación con un feed GTFS existente. Todos los ID de entidades se resuelven en relación con el feed GTFS. - -Un feed depende de algunas configuraciones externas: - -* El feed GTFS correspondiente. -* La aplicación del feed (actualizaciones, posiciones o alertas). Un feed debe contener únicamente elementos de las aplicaciones correspondientes; todas las otras entidades se ignorarán. -* Frecuencia de sondeo, controlada por min_update_delay, max_update_delay. - -### Campos - -| _**Nombre del campo**_ | _**Tipo**_ | _**Cardinalidad**_ | _**Descripción**_ | -|------------------------|------------|--------------------|-------------------| -| **header** | [FeedHeader](#mensaje-feedheader) | obligatorio | Metadatos sobre este feed y mensaje del feed | -| **entity** | [FeedEntity](#mensaje-feedentity) | repetido | Contenido del feed | - -## _mensaje_ FeedHeader - -Metadatos sobre un feed, incluido en los mensajes del feed: - -### Campos - -| _**Nombre del campo**_ | _**Tipo**_ | _**Cardinalidad**_ | _**Descripción**_ | -|------------------------|------------|--------------------|-------------------| -| **gtfs_realtime_version** | [string](https://developers.google.com/protocol-buffers/docs/proto#scalar) | obligatorio | Especificación de la versión del feed. La versión actual es 1.0. | -| **incrementality** | [Incrementality](#enum-incrementality) | opcional | -| **timestamp** | [uint64](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | Esta marca de tiempo identifica el momento en que se ha creado el contenido de este feed (en la hora del servidor). En POSIX time (es decir, cantidad de segundos desde el 1 de enero de 1970 00:00:00 UTC). Para evitar el desvío de tiempos entre los sistemas que producen y que consumen información en tiempo real, se recomienda derivar la marca de tiempo desde un servidor de tiempo. Es completamente aceptable usar Stratum 3 o incluso servidores strata inferiores, porque diferencias de tiempo de hasta un par de segundos son tolerables. | - -## _enum._ Incrementality - -Determina si la búsqueda actual es incremental. - -* **FULL_DATASET**: la actualización de este feed sobrescribirá toda la información en tiempo real anterior para el feed. Por lo tanto, se espera que esta actualización proporcione un resumen completo de toda la información en tiempo real conocida. -* **DIFFERENTIAL**: en este momento, este modo **no tiene soporte** y su comportamiento es **indefinido** para los feeds que lo usan. Existen debates en la [lista de correo](http://groups.google.com/group/gtfs-realtime) de GTFS en tiempo real relacionados con la especificación completa del comportamiento del modo DIFFERENTIAL, y la documentación se actualizará cuando esos debates finalicen. - -### Valores - -| _**Valor**_ | -|-------------| -| **FULL_DATASET** | -| **DIFFERENTIAL** | - -## _mensaje_ FeedEntity - -La definición (o actualización) de una entidad en el feed de transporte público. Si la entidad no se elimina, uno de los campos "trip_update", "vehicle" y "alert" debe completarse. - -### Campos - -| _**Nombre del campo**_ | _**Tipo**_ | _**Cardinalidad**_ | _**Descripción**_ | -|------------------------|------------|--------------------|-------------------| -| **id** | [string](https://developers.google.com/protocol-buffers/docs/proto#scalar) | obligatorio | Identificador único del feed para esta entidad. Los identificadores se usan solamente para proporcionar soporte de incrementalidad. Las entidades reales a las que hace referencia el feed deben especificarse mediante selectores explícitos (ver EntitySelector más adelante para obtener más información). | -| **is_deleted** | [bool](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | Establece si esta entidad debe eliminarse. Es relevante solo para las búsquedas incrementales. | -| **trip_update** | [TripUpdate](#mensaje-tripupdate) | opcional | Datos sobre las demoras de salida en tiempo real de un viaje. | -| **vehicle** | [VehiclePosition](#mensaje-vehicleposition) | opcional | Datos sobre la posición en tiempo real de un vehículo. | -| **alert** | [Alert](#mensaje-alert) | opcional | Datos sobre las alertas en tiempo real. | - -## _mensaje_ TripUpdate - -Actualización en tiempo real del progreso de un vehículo en un viaje. Consulta también el debate general del [tipo de feed de actualizaciones del viaje](./trip-updates). - -Según el valor de ScheduleRelationship, TripUpdate puede especificar lo siguiente: - -* Un viaje que avanza según la programación. -* Un viaje que avanza por una ruta, pero que no tiene una programación fija. -* Un viaje que se ha agregado o se ha quitado en relación con una programación. - -Las actualizaciones pueden ser para eventos de llegada/salida futuros y previstos, o para eventos pasados que ya ocurrieron. En la mayoría de los casos, la información sobre los eventos pasados es un valor medido, por lo tanto, se recomienda que su valor de incertidumbre sea 0\. Aunque puede haber algunos casos en que esto no sea así, por lo que se admiten valores de incertidumbre distintos de 0 para los eventos pasados. Si el valor de incertidumbre de una actualización no es 0, entonces la actualización es una predicción aproximada para un viaje que no se ha completado o la medición no es precisa o la actualización fue una predicción para el pasado que no se ha verificado después de que ocurrió el evento. - -Ten en cuenta que la actualización puede describir un viaje que ya se ha completado. En este caso, es suficiente con proporcionar una actualización para la última parada del viaje. Si el tiempo de llegada para la última parada es en el pasado, el cliente concluirá que todo el viaje es pasado (es posible, aunque inconsecuente, proporcionar también actualizaciones para las paradas anteriores). Esta opción es más relevante para un viaje que se ha completado antes de lo que establecía la programación, pero que según esta, el viaje todavía se está realizando en este momento. Quitar las actualizaciones de este viaje podría hacer que el cliente considere que el viaje todavía se está realizando. Ten en cuenta que el proveedor del feed tiene permitido, aunque no está obligado, a purgar las actualizaciones pasadas (en este caso esto sería útil). - -### Campos - -| _**Nombre del campo**_ | _**Tipo**_ | _**Cardinalidad**_ | _**Descripción**_ | -|------------------------|------------|--------------------|-------------------| -| **trip** | [TripDescriptor](#mensaje-tripdescriptor) | obligatorio | El viaje al cual se aplica este mensaje. Puede haber una entidad de TripUpdate, como máximo, para cada instancia de viaje real. Si no hay ninguna, entonces no habrá información de predicciones disponible. *No* significa que el viaje se está realizando de acuerdo con la programación. | -| **vehicle** | [VehicleDescriptor](#VehicleDescriptor) | opcional | Información adicional sobre el vehículo con el cual se está realizando este viaje. | -| **stop_time_update** | [StopTimeUpdate](#mensaje-stoptimeupdate) | repetido | Las actualizaciones de StopTimes para el viaje (futuras, como las predicciones, y, en algunos casos, pasadas, es decir, aquellas que ya ocurrieron). Las actualizaciones deben ordenarse por secuencia de parada y deben aplicarse a todas las siguientes paradas del viaje hasta la próxima especificada. | -| **timestamp** | [uint64](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | Momento en el que se midió el progreso en tiempo real del vehículo. En POSIX time (es decir, la cantidad de segundos desde el 1 de enero de 1970 00:00:00 UTC). | - -## _mensaje_ StopTimeEvent - -Información de horarios para un único evento previsto (sea la llegada o la salida). Los horarios consisten en la información sobre demoras o tiempos estimados y la incertidumbre. - -* La demora (delay) debe usarse cuando la predicción se realiza con relación a una programación existente en GTFS. -* El tiempo (time) debe darse aunque no haya una programación prevista. Si se especifican tanto el tiempo como la demora, el tiempo será prioritario (aunque, por lo general, el tiempo, si se otorga para un viaje programado, debe ser igual al tiempo programado en GTFS + la demora). - -La incertidumbre se aplica de la misma forma tanto al tiempo como a la demora. La incertidumbre especifica el error esperado en una demora real (pero ten en cuenta, que todavía no definimos su significado estadístico concreto). Es posible que la incertidumbre sea 0, por ejemplo, para los trenes que funcionan con un control de horarios por computadora. - -### Campos - -| _**Nombre del campo**_ | _**Tipo**_ | _**Cardinalidad**_ | _**Descripción**_ | -|------------------------|------------|--------------------|-------------------| -| **delay** | [int32](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | La demora (en segundos) puede ser positiva (significa que el vehículo está retrasado) o negativa (significa que el vehículo está adelantado). Una demora de 0 significa que el vehículo está yendo a tiempo. | -| **time** | [int64](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | Evento como tiempo absoluto. En POSIX time (es decir, la cantidad de segundos desde el 1 de enero de 1970 00:00:00 UTC). | -| **uncertainty** | [int32](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | Si se omite la incertidumbre, se interpreta como desconocida. Para especificar una predicción completamente certera, establece la incertidumbre en 0. | - -## _mensaje_ StopTimeUpdate - -La actualización en tiempo real para los eventos de llegada o de salida para una determinada parada de un viaje. Consulta el debate general de las actualizaciones de tiempos de parada en la documentación de [TripDescriptor](#mensaje-tripdescriptor) y [del tipo de feed de actualizaciones de viaje](./trip-updates). - -Las actualizaciones se pueden proporcionar tanto para eventos pasados como futuros. El productor tiene permitido, aunque no está obligado a, desestimar los eventos pasados. - La actualización está vinculada a una parada específica sea a través de stop_sequence o de stop_id, de manera que uno de estos campos debe definirse, necesariamente. - -### Campos - -| _**Nombre del campo**_ | _**Tipo**_ | _**Cardinalidad**_ | _**Descripción**_ | -|------------------------|------------|--------------------|-------------------| -| **stop_sequence** | [uint32](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | Debe ser la misma que la de stop_times.txt en el feed GTFS correspondiente. | -| **stop_id** | [string](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | Debe ser el mismo que el de stops.txt en el feed GTFS correspondiente. | -| **arrival** | [StopTimeEvent](#mensaje-stoptimeevent) | opcional | -| **departure** | [StopTimeEvent](#mensaje-stoptimeevent) | opcional | -| **schedule_relationship** | [ScheduleRelationship](#enum-schedulerelationship) | opcional | La relación predeterminada es SCHEDULED. | - -## _enum._ ScheduleRelationship - -La relación entre este StopTime y la programación estática - -### Valores - -| _**Valor**_ | _**Comentario**_ | -|-------------|------------------| -| **SCHEDULED** | El vehículo está avanzando según su programación estática de paradas, aunque no necesariamente de acuerdo con los tiempos de la programación. Este es el comportamiento **predeterminado**. Al menos debe proporcionarse uno de los valores de llegada y de salida. Si la programación para esta parada contiene los tiempos de llegada y de salida, entonces también debe contener estos dos valores la actualización. Una actualización son solo una salida, digamos, cuando la programación tiene ambos datos, indica que el viaje se termina antes en esta parada. | -| **SKIPPED** | La parada se omite, es decir, el vehículo no se detendrá en esta parada. Los valores de llegada y salida son opcionales. | -| **NO_DATA** | No se proporcionan datos para esta parada. Esto indica que no hay información en tiempo real disponible. Cuando se establece NO_DATA, esto se propaga en las siguientes paradas, de manera que esta es la forma recomendada de especificar desde qué parada no tienes información en tiempo real. Cuando se establece NO_DATA, no se deben proporcionar los datos de llegada ni de salida. | - -## _mensaje_ VehiclePosition - -Información de posicionamiento en tiempo real para un vehículo dado - -### Campos - -| _**Nombre del campo**_ | _**Tipo**_ | _**Cardinalidad**_ | _**Descripción**_ | -|------------------------|------------|--------------------|-------------------| -| **trip** | [TripDescriptor](#mensaje-tripdescriptor) | opcional | El viaje que está haciendo este vehículo. Puede estar vacío o parcialmente vacío si el vehículo no puede identificarse con una instancia de viaje dada. | -| **vehicle** | [VehicleDescriptor](#VehicleDescriptor) | opcional | Información adicional sobre el vehículo que está realizando el viaje. Cada entrada debe tener un ID de vehículo **único**. | -| **position** | [Position](#mensaje-position) | opcional | Posición actual de este vehículo. | -| **current_stop_sequence** | [uint32](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | El índice de la secuencia de parada de la parada actual. El significado de current_stop_sequence (es decir, la parada a la que hace referencia) está determinado por current_status. Si falta el valor en current_status, se asume IN_TRANSIT_TO. | -| **stop_id** | [string](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | Identifica la parada actual. El valor debe ser el mismo que el de stops.txt en el feed GTFS correspondiente. | -| **current_status** | [VehicleStopStatus](#VehicleStopStatus) | opcional | El estado exacto del vehículo con respecto a la parada actual. Se ignora si falta el valor en current_stop_sequence. | -| **timestamp** | [uint64](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | Momento en el cual se midió la posición del vehículo. En POSIX time (es decir, la cantidad de segundos desde el 1 de enero de 1970 00:00:00 UTC). | -| **congestion_level** | [CongestionLevel](#CongestionLevel) | opcional | - -## _enum._ VehicleStopStatus - -### Valores - -| _**Valor**_ | _**Comentario**_ | -|-------------|------------------| -| **INCOMING_AT** | El vehículo está a punto de llegar a la parada (en la visualización de la parada, el símbolo del vehículo, por lo general, parpadea). | -| **STOPPED_AT** | El vehículo está detenido en la parada. | -| **IN_TRANSIT_TO** | El vehículo ha salido de la parada anterior y está en tránsito. | - -## _enum._ CongestionLevel - -El nivel de tráfico que está afectando al vehículo. - -### Valores - -| _**Valor**_ | -|-------------| -| **UNKNOWN_CONGESTION_LEVEL** | -| **RUNNING_SMOOTHLY** | -| **STOP_AND_GO** | -| **CONGESTION** | -| **SEVERE_CONGESTION** | - -## _mensaje_ Alert - -Una alerta que indica que existe algún tipo de incidente en la red de transporte público. - -### Campos - -| _**Nombre del campo**_ | _**Tipo**_ | _**Cardinalidad**_ | _**Descripción**_ | -|------------------------|------------|--------------------|-------------------| -| **active_period** | [TimeRange](#mensaje-timerange) | repetido | Tiempo durante el cual debe mostrarse la alerta al usuario. Si falta, la alerta se mostrará durante todo el tiempo que aparezca en el feed. Si se otorgan varios intervalos, la alerta se mostrará durante todos ellos. | -| **informed_entity** | [EntitySelector](#mensaje-entitySelector) | repetido | Entidades a cuyos usuarios debemos notificar esta alerta. | -| **cause** | [Cause](#enum-cause) | opcional | -| **effect** | [Effect](#enum-effect) | opcional | -| **url** | [TranslatedString](#mensaje-translatedstring) | opcional | La URL que proporciona información adicional sobre la alerta. | -| **header_text** | [TranslatedString](#mensaje-translatedstring) | opcional | Encabezado de la alerta. Esta cadena de texto sin formato se resaltará, por ejemplo, en negrita. | -| **description_text** | [TranslatedString](#mensaje-translatedstring) | opcional | Descripción de la alerta. A esta cadena de texto sin formato se le aplicará el formato del cuerpo de la alerta (o se mostrará en una solicitud explícita de "expansión" realizada por el usuario
). La información de la descripción debe completar la información del encabezado. | - -## _enum._ Cause - -Causa de la alerta - -### Valores - -| _**Valor**_ | -|-------------| -| **UNKNOWN_CAUSE** | -| **OTHER_CAUSE** | -| **TECHNICAL_PROBLEM** | -| **STRIKE** | -| **DEMONSTRATION** | -| **ACCIDENT** | -| **HOLIDAY** | -| **WEATHER** | -| **MAINTENANCE** | -| **CONSTRUCTION** | -| **POLICE_ACTIVITY** | -| **MEDICAL_EMERGENCY** | - -## _enum._ Effect - -El efecto de este problema en la entidad afectada. - -### Valores - -| _**Valor**_ | -|-------------| -| **NO_SERVICE** | -| **REDUCED_SERVICE** | -| **SIGNIFICANT_DELAYS** | -| **DETOUR** | -| **ADDITIONAL_SERVICE** | -| **MODIFIED_SERVICE** | -| **OTHER_EFFECT** | -| **UNKNOWN_EFFECT** | -| **STOP_MOVED** | - -## _mensaje_ TimeRange - -Un intervalo de tiempo. El intervalo se considera activo `t` si `t` es mayor o igual que la hora de inicio y mejor que la hora de finalización. - -### Campos - -| _**Nombre del campo**_ | _**Tipo**_ | _**Cardinalidad**_ | _**Descripción**_ | -|------------------------|------------|--------------------|-------------------| -| **start** | [uint64](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | Hora de inicio, en POSIX time (es decir, la cantidad de segundos desde el 1 de enero de 1970 00:00:00 UTC). Si falta esta información, el intervalo comienza con el valor infinito negativo. | -| **end** | [uint64](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | Hora de finalización, en POSIX time (es decir, la cantidad de segundos desde el 1 de enero de 1970 00:00:00 UTC). Si falta esta información, el intervalo finaliza con el valor infinito positivo. | - -## _mensaje_ Position - -La posición geográfica de un vehículo - -### Campos - -| _**Nombre del campo**_ | _**Tipo**_ | _**Cardinalidad**_ | _**Descripción**_ | -|------------------------|------------|--------------------|-------------------| -| **latitude** | [float](https://developers.google.com/protocol-buffers/docs/proto#scalar) | obligatorio | Grados norte, en el sistema de coordenadas WGS-84 | -| **longitude** | [float](https://developers.google.com/protocol-buffers/docs/proto#scalar) | obligatorio | Grados este, en el sistema de coordenadas WGS-84 | -| **bearing** | [float](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | Orientación, en grados, en el sentido de las agujas del reloj desde el norte verdadero, es decir, 0 es el norte y 90 es el este. Esta puede ser la orientación de la brújula, o la dirección hacia la próxima parada o la ubicación intermedia. Esto no debe deducirse a partir de la secuencia de posiciones anteriores, que los clientes pueden calcular a partir de los datos anteriores. | -| **odometer** | [double](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | El valor del odómetro en metros. | -| **speed** | [float](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | Velocidad momentánea medida por el vehículo, en metros por segundo. | - -## _mensaje_ TripDescriptor - -Un descriptor que identifica una instancia de un viaje de GTFS o todas las instancias de un viaje por una ruta. Para especificar una sola instancia de viaje, se define trip_id (y si fuera necesario, start_time). Si también se define route_id, debe ser el mismo que uno a los cuales corresponda el viaje dado. Para especificar todos los viajes de una determinada ruta, solo se debe definir route_id. Ten en cuenta que si no se conoce el trip_id, entonces los identificadores de la secuencia de la estación en TripUpdate no son suficientes y, también, se deberán proporcionar los identificadores de parada. Además, se deben proporcionar las horas absolutas de llegada/salida. - -### Campos - -| _**Nombre del campo**_ | _**Tipo**_ | _**Cardinalidad**_ | _**Descripción**_ | -|------------------------|------------|--------------------|-------------------| -| **trip_id** | [string](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | El identificador de viaje del feed GTFS al cual hace referencia este selector. Para los viajes sin frecuencia extendida, este campo es suficiente para identificar de forma unívoca al viaje. Para los viajes con frecuencia extendida, también podrían necesitarse start_time y start_date. | -| **route_id** | [string](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | El identificador de la ruta de GTFS al que hace referencia este selector. | -| **start_time** | [string](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | La hora de inicio programada de esta instancia de viaje. Este campo debe proporcionarse solo si el viaje tiene frecuencia extendida en el feed GTFS. El valor debe corresponder precisamente a la hora de inicio especificada para la ruta del feed GTFS más algunos múltiplos de headway_secs. El formato del campo es el mismo que el de GTFS/frequencies.txt/start_time, es decir, 11:15:35 o 25:15:35. | -| **start_date** | [string](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | La fecha de inicio programada de esta instancia de viaje. Este campo debe proporcionarse para desambiguar los viajes que están tan retrasados que pueden superponerse con un viaje programado para el día siguiente. Por ejemplo, para un tren que sale a las 8:00 y a las 20:00 todos los días, y está 12 horas retrasado, habrá dos viajes distintos a la misma hora. Este campo puede proporcionarse, pero no es obligatorio para las programaciones en las cuales las superposiciones son imposibles, por ejemplo, un servicio que funciona según una programación horaria donde un vehículo que está una hora retrasado deja de considerarse relacionado a la programación. En formato AAAAMMDD. | -| **schedule_relationship** | [ScheduleRelationship](#enum-schedulerelationship-1) | opcional | - -## _enum._ ScheduleRelationship - -La relación entre este viaje y la programación estática. Si un viaje se realiza de acuerdo con la programación temporal, no se refleja en GTFS, y por lo tanto, no debe marcarse como SCHEDULED, sino como ADDED. - -### Valores - -| _**Valor**_ | _**Comentario**_ | -|-------------|------------------| -| **SCHEDULED** | Viaje que se está realizando de acuerdo con su programación de GTFS, o que está realizándose tan parecido al viaje programado que se puede asociar con él. | -| **ADDED** | Un viaje adicional que se agregó además de una programación existente, por ejemplo, para reemplazar un vehículo averiado o para responder a una carga repentina de pasajeros. | -| **UNSCHEDULED** | Un viaje que se está realizando sin ninguna programación asociada, por ejemplo, cuando no existe ninguna programación. | -| **CANCELED** | Un viaje que existió en la programación, pero que luego se eliminó. | -| **REPLACEMENT** | Un viaje que reemplaza una parte de la programación estática. Si el selector de viaje identifica determinada instancia de viaje, entonces solamente esa instancia se reemplaza. Si el selector identifica una ruta, entonces todos los viajes de la ruta se reemplazan.
El reemplazo se aplica solamente a la parte del viaje que se suministra. Por ejemplo, consideremos una ruta que pasa por las paradas A,B,C,D,E,F y un viaje REPLACEMENT proporciona datos para las paradas A,B,C. Entonces, los horarios para las paradas D,E,F todavía se toman de la programación estática.
Un feed debe suministrar varios viajes REPLACEMENT. En este caso, la parte de la programación estática que se reemplaza es la suma de las definiciones de todos los feeds. Por lo general, todos los viajes REPLACEMENT deben corresponder a la misma ruta o a instancias de viaje individuales. | - -## _mensaje_ VehicleDescriptor - -Información de identificación para el vehículo que realiza el viaje. - -### Campos - -| _**Nombre del campo**_ | _**Tipo**_ | _**Cardinalidad**_ | _**Descripción**_ | -|------------------------|------------|--------------------|-------------------| -| **id** | [string](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | Identificación interna del sistema para el vehículo. Debe ser **única** para cada vehículo y se usa para hacer un seguimiento del vehículo en la medida en que avanza en el sistema. Este identificador debe ser visible para el usuario final; para ello debes usar el campo **label** | -| **label** | [string](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | Etiqueta visible para el usuario, es decir, que se debe mostrar al pasajero para ayudarlo a identificar el vehículo correcto. | - -## _mensaje_ EntitySelector - -Un selector para una entidad en un feed GTFS. Los valores de los campos deben coincidir con los campos correspondientes del feed GTFS. Debe otorgarse al menos un especificador. Si se otorgan muchos, entonces la coincidencia debe hacerse con todos los especificadores dados. - -### Campos - -| _**Nombre del campo**_ | _**Tipo**_ | _**Cardinalidad**_ | _**Descripción**_ | -|------------------------|------------|--------------------|-------------------| -| **agency_id** | [string](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | -| **route_id** | [string](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | -| **route_type** | [int32](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | -| **trip** | [TripDescriptor](#mensaje-tripdescriptor) | opcional | -| **stop_id** | [string](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | - -## _mensaje_ TranslatedString - -Un mensaje internacionalizado que contiene versiones por idioma de un fragmento de texto o una URL. Se seleccionará una de las cadenas de un mensaje. La resolución se realiza de la siguiente manera: si el idioma de la UI coincide con el código de idioma de una traducción, se elije la primera traducción coincidente. Si un idioma de UI predetermiando (por ejemplo, inglés) coincide con el código de idioma de una traducción, se elije la primera traducción coincidente. Si alguna traducción tiene un código de idioma no especificado, se elija esa traducción. - -### Campos - -| _**Nombre del campo**_ | _**Tipo**_ | _**Cardinalidad**_ | _**Descripción**_ | -|------------------------|------------|--------------------|-------------------| -| **translation** | [Translation](#mensaje-translation) | repetido | Se debe proporcionar al menos una traducción. | - -## _mensaje_ Translation - -Una cadena localizada asignada a un idioma. - -### Campos - -| _**Nombre del campo**_ | _**Tipo**_ | _**Cardinalidad**_ | _**Descripción**_ | -|------------------------|------------|--------------------|-------------------| -| **text** | [string](https://developers.google.com/protocol-buffers/docs/proto#scalar) | obligatorio | Una cadena UTF-8 que contiene el mensaje. | -| **language** | [string](https://developers.google.com/protocol-buffers/docs/proto#scalar) | opcional | Código de idioma BCP-47\. Se puede omitir si el idioma es desconocido o si no se realiza ninguna internacionalización para el feed. Al menos una traducción puede tener una etiqueta de idioma no especificado. | diff --git a/gtfs-realtime/spec/es/service-alerts.md b/gtfs-realtime/spec/es/service-alerts.md deleted file mode 100644 index 4161622ba..000000000 --- a/gtfs-realtime/spec/es/service-alerts.md +++ /dev/null @@ -1,56 +0,0 @@ -Las alertas de servicio permiten proporcionar actualizaciones cada vez que se produce una interrupción en la red. Las demoras y cancelaciones de viajes individuales a menudo se deben comunicar a través de las [Actualizaciones de viaje](trip-updates.md). - -Se puede proporcionar la siguiente información: - -* la URL del sitio en el que se ofrecen más detalles acerca de la alerta, -* el texto del encabezado a modo de resumen de la alerta, -* la descripción completa de la alerta que se mostrará junto al encabezado (la información no debe ser la misma en ambas partes). - -### Período - -La alerta aparecerá en el momento apropiado, dentro del período establecido. Este período debe cubrir en su totalidad el lapso en el que el pasajero necesita la alerta. - -Si no se establece ningún período, mostraremos la alerta durante el tiempo en que esta se encuentre en el feed. Si se establecen varios períodos, mostraremos la alerta durante todos ellos. - -### Selector de entidad - -El selector de entidad permite especificar exactamente a qué partes de la red afecta una alerta, con el fin de poder mostrar al usuario sólo las alertas más adecuadas. Varios selectores de entidad pueden ser incluidos, para los casos en los que las alertas afecten a muchas entidades. - -Las entidades se seleccionan a través de los identificadores de la especificación GTFS, pudiéndose elegir entre: - -* Empresa: afecta toda la red. -* Ruta: afecta toda la ruta. -* Tipo de ruta: afecta cualquier ruta del tipo seleccionado; p. ej.: todos los metros. -* Viaje: afecta un viaje en particular. -* Parada: afecta una parada en particular. - -### Causa - -¿Cuál es la causa de esta alerta? Se pueden especificar cualquiera de las siguientes: - -* causa desconocida, -* otra causa (que no se ve representada por ninguna de estas opciones), -* problema técnico, -* huelga, -* manifestación, -* accidente, -* feriado, -* clima, -* tareas de mantenimiento, -* tareas de construcción, -* actividad policial, -* emergencia médica. - -### Consecuencia - -¿Qué conscuencia tiene este problema para la entidad seleccionada? Se pueden especificar cualquiera de las siguientes: - -* sin servicio, -* servicio reducido, -* demoras importantes (aquellas poco importantes se deben informar a través de las [Actualizaciones de viaje](trip-updates.md)), -* desvío, -* servicio adicional, -* servicio modificado, -* traslado de parada, -* otro efecto (que no se ve representado por ninguna de estas opciones), -* efecto desconocido. diff --git a/gtfs-realtime/spec/es/trip-updates.md b/gtfs-realtime/spec/es/trip-updates.md deleted file mode 100644 index a4d5fc5a6..000000000 --- a/gtfs-realtime/spec/es/trip-updates.md +++ /dev/null @@ -1,56 +0,0 @@ -Las actualizaciones de viaje representan fluctuaciones en el horario. Se espera recibirlas de todos los viajes programados que puedan proporcionarlas en tiempo real. Estas actualizaciones brindarían un horario de llegada o salida previsto para las paradas a lo largo de la ruta. Las actualizaciones de viaje también pueden prever escenarios más complejos en los cuales se cancelen o agreguen viajes al programa, o incluso se redirijan. - -**Recordatorio:** En [GTFS](https://developers.google.com/transit/gtfs/), un viaje es una secuencia de dos o más paradas que tienen lugar a una hora específica. - -Debe haber **como máximo** una actualización de viaje para cada viaje programado. En caso de no ser así, se concluirá que no hay datos en tiempo real disponibles para dicho viaje. El consumidor de datos **no** debe asumir que el viaje se está realizando de manera puntual. - -## Actualizaciones de horario de paradas - -Una actualización de viaje comprende una o más actualizaciones de los horarios de parada del vehículo, conocidas como [StopTimeUpdates](reference.md#StopTimeUpdate). Pueden proporcionarse para horarios de paradas pasados y futuros. Se permite brindar horarios de parada pasados, pero no es obligatorio hacerlo. En el caso de que se haga, ten en cuenta que no se debe proporcionar una actualización pasada si se refiere a un viaje todavía no programado para haber terminado (es decir, que finalizó antes de lo programado), ya que, de lo contrario, se concluirá que no hay actualización de ese viaje. - -Cada [StopTimeUpdate](reference.md#StopTimeUpdate) está vinculada a una parada. Normalmente esto se puede hacer usando un GTFS stop_sequence o un GTFS stop_id. Sin embargo, en caso de que estés suministrando una actualización para un viaje sin un trip_id de GTFS, debes especificar el stop_id, ya que stop_sequence no tiene valor. El stop_id todavía debe hacer referencia a un stop_id en GTFS. - -La actualización puede proporcionar un horario exacto para la **llegada** o la **salida** en una parada en [StopTimeUpdates](reference.md#StopTimeUpdate) mediante [StopTimeEvent](reference.md#StopTimeUpdate). Este debe contener un **horario** absoluto o un **retraso** (es decir, una compensación desde el horario programado en segundos). El retraso solo se puede utilizar en caso de que la actualización de viaje se refiera a un viaje de GTFS programado, en contraposición con un viaje basado en la frecuencia. En este caso, el horario debe ser igual al horario programado + el retraso. También se debe especificar la **incertidumbre** de la predicción junto con [StopTimeEvent](reference.md#StopTimeUpdate), que se analiza más detalladamente más abajo, en la sección [Incertidumbre](#Incertidumbre). - -Para cada [StopTimeUpdate](reference.md#StopTimeUpdate), la relación de programación predeterminada es **programada**. (Ten en cuenta que ésta es diferente a la relación de programación para el viaje). Puedes cambiarla a **omitida** si la parada no se va a utilizar o a **sin datos** si solo tienes datos en tiempo real para parte del viaje. - -**Las actualizaciones se deben clasificar por stop_sequence** (o stop_id, en el orden en que tienen lugar en el viaje). - -Si faltan una o más paradas a lo largo del viaje, la actualización se propaga a todas las paradas subsiguientes. Esto significa que, en caso de no haber otra información, al actualizar un horario de parada para una cierta parada se cambiarán todas las paradas subsiguientes. - -**Ejemplo 1** - -Para un viaje con 20 paradas, una [StopTimeUpdate](reference.md#StopTimeUpdate) con retraso de llegada y retraso de salida de 0 ([StopTimeEvents](reference.md#StopTimeEvent)) para la stop_sequence de la parada actual, significa que el viaje está exactamente a horario. - -**Ejemplo 2** - -Para la misma instancia de viaje, se proporcionan tres [StopTimeUpdates](reference.md#StopTimeUpdate): - -* retraso de 300 segundos para la stop_sequence 3. -* retraso de 60 segundos para la stop_sequence 8. -* retraso de duración no especificada para la stop_sequence 10. - -Esto se interpretará como: - -* las stop_sequences 3,4,5,6,7 tienen un retraso de 300 segundos. -* las stop_sequences 8,9 tienen un retraso de 60 segundos. -* las stop_sequences 10,..,20 tienen un retraso desconocido. - -### Descriptor de viajes - -La información suministrada por el descriptor de viajes depende de la relación de programación del viaje que estás actualizando. Hay varias opciones que puedes configurar: - -| _**Valor**_ | _**Comentario**_ | -|-------------|------------------| -| **Programado** | Este viaje se está ejecutando de acuerdo con un programa de GTFS o se asemeja lo suficiente como para seguir estando asociado a él. | -| **Agregado** | Este viaje no estaba programado y se ha agregado. Por ejemplo, para satisfacer la demanda o reemplazar un vehículo averiado. | -| **Sin programar** | Este viaje está teniendo lugar, pero nunca está asociado con horario alguno. Por ejemplo, si no hay programa y los autobuses operan en un servicio de traslados. | -| **Cancelado** | Este viaje se programó pero ahora está eliminado. | - -En la mayoría de los casos, se debe proporcionar el trip_id del viaje programado en GTFS con el que se relaciona esta actualización. En caso de que no se pueda vincular esta actualización con un viaje en GTFS, se puede brindar un route_id de GTFS, y una fecha y hora de inicio para el viaje. Generalmente, este es el caso de los viajes agregados, los que están sin programar y de algunos tipos de viajes de reemplazo. - -## Incertidumbre - -La incertidumbre se aplica tanto al horario como al valor de retraso de una [StopTimeUpdate](reference.md#StopTimeUpdate). La incertidumbre especifica, en términos generales, el error esperado en el retraso real como un entero en segundos (pero ten en cuenta que el significado estadístico concreto todavía no está definido). Es posible que la incertidumbre sea 0, por ejemplo, para los trenes conducidos bajo control de horarios por computadora. - -Por ejemplo, un autobús de larga distancia que tiene un retraso estimado de 15 minutos y llega a su siguiente parada con una ventana de error de 4 minutos (es decir, +2/-2 minutos) tendrá una incertidumbre de 240. diff --git a/gtfs-realtime/spec/es/vehicle-positions.md b/gtfs-realtime/spec/es/vehicle-positions.md deleted file mode 100644 index d8191696c..000000000 --- a/gtfs-realtime/spec/es/vehicle-positions.md +++ /dev/null @@ -1,59 +0,0 @@ -La posición del vehículo se utiliza para proporcionar información generada automáticamente sobre la ubicación del mismo, como la generada por un GPS a bordo. Se debe proporcionar una sola posición por cada vehículo que pueda hacerlo. - -El viaje que el vehículo está realizando actualmente se debe proporcionar a través de un [descriptor de viaje](reference.md#VehicleDescriptor). También se puede proporcionar un [descriptor de vehículo](reference.md#VehicleDescriptor) que especifique un vehículo físico concreto sobre el cual estás proporcionando actualizaciones. La documentación se proporciona más abajo. - -Se puede proporcionar una **marca de tiempo** que indique el momento en el que se tomó la lectura de la posición. Hay que tener en cuenta que esta es diferente de la marca de tiempo en el encabezado del feed, que es el tiempo en el que el servidor generó este mensaje. - -También se puede proporcionar un **paso actual** (ya sea como stop_sequence o stop_id). Este es una referencia a la parada a la que el vehículo se está dirigiendo o en la que ya se detuvo. - -## Posición - -La posición contiene los datos de ubicación (Vehicle Position) del vehículo. Los campos de latitud y longitud son obligatorios; los demás campos son opcionales. Estos tipos de datos son: - -* **Latitud**: grados Norte, en el sistema de coordenadas WGS-84. -* **Longitud**: grados Este, en el sistema de coordenadas WGS-84. -* **Rumbo**: la dirección hacia la que el vehículo está orientado. -* **Odómetro**: la distancia que el vehículo ha recorrido. -* **Velocidad**: velocidad instantánea medida por el vehículo, en metros por segundo. - -## Nivel de tráfico - -La posición del vehículo también permite que la empresa especifique el nivel de tráfico que el vehículo está experimentando en el instante actual. El tráfico se puede clasificar en las siguientes categorías: - -* Nivel de tráfico desconocido. -* Tráfico fluido. -* Tráfico intermitente. -* Atasco. -* Atrasco grave. - -A la empresa le corresponde interpretar nuestra ponderación del tráfico. Desde nuestra perspectiva, la congestión grave solo se utilizaría en situaciones en las que el tráfico está tan congestionado que las personas están abandonando sus vehículos. - -## Grado de ocupación del vehículo - -La posición del vehículo permite a la empresa especificar el grado de ocupación del vehículo, que puede ser clasificado en la siguientes categorías: - -* Vacío. -* Muchos asientos libres. -* Pocos asientos libres. -* Sitio sólo de pie. -* Sitio sólo de pie y apretados. -* Lleno. -* No admite más pasajeros. - -Este campo todavía es **experimental** y está sujeto a cambios. Podría pasar a adoptarse formalmente más adelante. - -## Estado de parada del vehículo - -El estado de parada del vehículo está más relacionado con el estado de una parada a la que se está aproximando o en la que ya está. Se puede ajustar a cualquiera de estos valores. - -* **Llegando a**: el vehículo está a punto de llegar a la parada indicada. -* **Detenido en**: el vehículo está detenido en la parada indicada. -* **En camino a**: la parada indicada es la siguiente parada para el vehículo: **predeterminado**. - -## Descriptor de vehículo - -El descriptor de vehículo describe un vehículo físico concreto y puede contener cualquiera de los siguientes atributos: - -* **ID**: sistema interno de identificación del vehículo. Debe ser único para el vehículo. -* **Identificador**: un identificador visible para el usuario, por ejemplo el nombre de un tren. -* **Matrícula**: la matrícula real del vehículo.