Cambios

Introducción

La especificación GTFS no es definitiva. En cambio, es una especificación abierta, desarrollada y mantenida por la comunidad de empresas de transporte, programadores y otros interesados que usan GTFS. Se espera que esta comunidad de productores y consumidores de datos de GTFS tenga propuestas para extender la especificación a fin de habilitar nuevas capacidades. Para ayudar a realizar ese proceso, se han establecido los siguientes procedimientos y pautas.

El proceso de cambio

El esquema general para cambiar la especificación tiene una serie de pasos:

  1. Proponer un cambio en la lista de foros de debate de cambios de GTFS.
  2. Recibir comentarios y sugerencias de la comunidad de GTFS y reiterar el cambio propuesto.
  3. Encontrar al menos un productor y un consumidor de GTFS para implementar y probar el cambio propuesto.
  4. Enviar una solicitud de comentarios final sobre el cambio propuesto a la lista de foros de debate. Si no se identifican problemas pendientes luego del transcurso de una semana, la propuesta se adoptará oficialmente.

El grupo de foros de debate servirá como lugar primario para sugerir cambios a la especificación, de modo tal que los usuarios de GTFS puedan conocer y ofrecer comentarios sobre los cambios propuestos. Si la comunidad acuerda en forma general que la propuesta vale la pena y sigue los principios rectores de GTFS descritos a continuación, la propuesta se agregará oficialmente a la especificación. También solicitamos que cualquier cambio propuesto sea implementado por, al menos, un productor y un consumidor de GTFS, para poder verificar la viabilidad de ese cambio en la práctica.

Además del grupo de foros de debate, ten en cuenta que el sitio de cambios de GTFS se usará para documentar las propuestas existentes de cambios de GTFS a favor del grupo de foros de debate.

Principios rectores

Para preservar la visión original de GTFS, se han establecido una serie de principios rectores a tener en cuenta al extender la especificación:

Crear y editar feeds debe ser un proceso fácil

Elegimos CSV como base de la especificación debido a que es fácil para ver y editar mediante programas de hojas de cálculo y editores de texto, lo cual es útil para las empresas más pequeñas. Además es sencillo de generar desde la mayoría de los lenguajes de programación y bases de datos, lo cual es bueno para los editores de feeds más grandes.

Analizar feeds debe ser un proceso fácil

Los lectores de feeds deben ser capaces de extraer la información que buscan con el menor esfuerzo posible. Los cambios y adiciones al feed deben ser lo más útiles posible a fin de minimizar la cantidad de rutas de código que los lectores del feed deben implementar. (Sin embargo, se debe dar prioridad al proceso de facilitar la creación, ya que en última instancia habrá más editores que lectores de feeds).

Los cambios a la especificación deben ser compatibles con versiones anteriores

Al agregar funciones a la especificación, queremos evitar realizar cambios que provoquen que los feeds existentes no sean válidos. No queremos crear más trabajo para los editores de feeds existentes hasta que ellos no deseen agregar funciones a sus feeds. Además, siempre que sea posible, queremos que los analizadores existentes puedan continuar leyendo las partes más antiguas de los feeds más nuevos.

No se recomiendan las funciones especulativas

Cada nueva función agrega complejidad a la creación y lectura de los feeds. Por lo tanto, queremos ser cuidadosos para solo agregar funciones que sabemos que serán útiles. Idealmente, cualquier propuesta habrá sido probada generando datos para un sistema de transporte público real que utiliza la nueva función y escribiendo software para leerlo y mostrarlo. Ten en cuenta que la GTFS siempre permite extensiones en el formato a través de la adición de columnas y archivos adicionales que son ignorados por los analizadores y validadores oficiales, de modo que las propuestas pueden incluir prototipos y ser probadas fácilmente en los feeds existentes.

Historial de revisiones

15 de octubre de 2012

  • Se agregó trips.txt con la propuesta de "wheelchair_accessible" (accesible para silla de ruedas) a la especificación: foros de debate.

20 de junio de 2012

  • Se agregó la propuesta de "wheelchair_boarding" (acceso con silla de ruedas) a la especificación: foros de debate.

2 de febrero de 2012

  • Se agregó la propuesta de "stop_timezone" (zona horaria de la parada) a la especificación: foros de debate.

18 de enero de 2012

26 de septiembre de 2011

  • Se agregó la propuesta de "feed_info" (información del feed) a la especificación: foros de debate.

6 de septiembre de 2011

  • Se agregó la propuesta de "agency_fare_url" (URL de tarifas de la empresa) a la especificación: foros de debate.
  • Se agregó la propuesta de "exact_times" (horarios exactos) a la especificación: foros de debate.

30 de marzo de 2009

  • Una nueva sección sobre cómo hacer que un feed de transporte esté disponible públicamente. Este tema no se debatió anteriormente en el grupo, ya que no era un cambio exclusivamente sobre cómo se interpretaban o escribían los datos. Sin embargo, cierta gente en Google pensó que sería informativo incluir un foro de debate de usos de GTFS no relativos a Google, ya que hay una cantidad cada vez mayor de aplicaciones que pueden utilizar los datos con formato GTFS.
  • Aclaraciones del formato CSV: foros de debate.
  • Orientación adicional sobre cómo elegir colores contrastantes en las descripciones de los campos route_color y route_text_color.
  • trip_short_name, según se propuso y probó en las siguientes cadenas: a y b.
  • Solución de un error menor en los datos de ejemplo incluidos al final del documento (en donde se da a la parada S7 el valor de parent_station S8).
  • Se agregó la información de "agency_lang" a los datos de ejemplo al final del documento, según lo sugerido por Marcy durante el período de comentarios: foros de debate.
  • Se actualizó el vínculo al feed GTFS de OCTA en la barra lateral.
  • Consulta resumen original.

26 de febrero de 2009

  • Se eliminó la mayoría de las instrucciones para el envío de feed específicas de Google, ya que hay muchas otras aplicaciones que consumen datos de GTFS en este punto.
  • Se corrigió un vínculo roto en la barra lateral del feed público de OCTA del Condado de Orange.

7 de agosto de 2008

  • Se restauró el campo stop_url, que se había omitido de manera fortuita en la versión del 6 de agosto.
  • Se agregó agency_phone a los datos de ejemplo.
  • Se agregó una mención del acuerdo de uso de datos al enviar un feed a Google.

6 de agosto de 2008

  • Se agregó el archivo transfers.txt, lo cual permite a los editores del feed proporcionar sugerencias sobre el comportamiento preferido de transferencia (propuesta original).
  • Se agregaron los campos location_type y parent_station al archivo stops.txt, lo cual permite agrupar los puntos de paradas en estaciones (propuesta original).
  • Se agregó el campo agency_phone para proporcionar un número de teléfono de voz a una empresa (propuesta original)
  • Se agregó la sección "Pruebas de feeds" en donde se mencionan las herramientas de las pruebas de código abierto.
  • Se agregaron aclaraciones sobre el formato CSV, agency_timezone, agency_lang, route_color, route_text_color, arrival_time, departure_time, calendar.txt contra calendar_dates.txt, fare tables y frequencies.txt.
  • Se agregó un vínculo al documento de historial del feed, y se corrigieron algunos vínculos de feeds públicos.
  • Se actualizaron las imágenes de ejemplo para describir la interfaz de usuario actual de Google Maps.
  • Se actualizaron y corrigieron los datos de ejemplo en el documento.

29 de febrero del 2008

  • Se agregó el campo stop_code en el archivo stops.txt para permitir la especificación de códigos de parada con vista hacia los pasajeros (propuesta original).
  • Se aclararon las descripciones de route_short_name y route_long_name en routes.txt.
  • Se aclararon las descripciones de arrival_time y departure_time en stop_times.txt.
  • Se corrigieron errores en la sección Datos de ejemplo.

20 de noviembre de 2007

  • Se aclaró la descripción de block_id.
  • Se cambió el idioma para desacentuar Google Transit (ya que las aplicaciones no relativas a Google utilizan GTFS y las rutas de transporte público ahora son una función integrada de Google Maps), y para corregir diversos errores.
  • Se actualizaron las capturas de pantalla de ejemplo para reflejar la presentación de campos GTFS en la interfaz de usuario actual de Google Maps.
  • Se actualizaron las direcciones de correo electrónico de contacto de Google para los proveedores de datos de transporte.
  • Se actualizaron los formatos.

5 de octubre de 2007

  • Se cambiaron stop_sequence y shape_pt_sequence para permitir cualquier aumento de enteros no negativos.
  • Se aclararon descripciones y se corrigieron errores.

31 de mayo de 2007

  • Se actualizó el estilo de la página; se limpió y brindó más acceso a la HTML.
  • Se agregaron vínculos en los ejemplos de feeds públicos y otros sitios útiles.
  • Se eliminaron los ejemplos de descripciones de campos individuales.

9 de abril de 2007

  • Se agregó la sección sobre el envío de un feed.
  • Se agregó el feed Demostración de ejemplo de la empresa de transporte público.
  • Se agregó una nota sobre que calendar.txt puede omitirse si todas las fechas del servicio se definen en calendar_dates.txt.
  • El campo agency_id se convirtió en opcional en los feeds que contenían solo una empresa. Esto permite que los feeds existentes sin agency_id continúen siendo válidos.
  • Se agregó una especificación más completa de agency_url, stop_url y route_url, y los valores de ejemplo adicionales para dichos campos.
  • Se agregaron 6 (Góndola) y 7 (Funicular) como valores válidos de route_type.

8 de marzo de 2007

  • Edición menor para trasladar el campo stop_url de stop_times.txt, donde se especificó de manera incorrecta en la actualización del 28 de febrero, a stops.txt, adonde pertenece.

5 de marzo de 2007

  • Edición menor para aclarar la descripción del campo route_long_name.

28 de febrero de 2007

  • Adición del archivo frequencies.txt para brindar asistencia de horarios basados en el tiempo entre trayectos.
  • En ese momento se permitieron muchas empresas en el mismo feed. También se agregó un nuevo campo agency_id tanto en agencies.txt como en routes.txt que te permiten especificar las rutas operadas por cada empresa.
  • Adición de URL por rutas y por paradas.
  • Adición del campo direction_id en trips.txt.
  • Asistencia para los cambios de letreros entre los trayectos con la adición del campo stop_headsign en stop_times.txt.
  • Asistencia para los colores de rutas con la adición de route_color y route_text_color opcional en routes.txt.
  • Se eliminó la capacidad de especificar paradas mediante direcciones postales. La versión anterior de la especificación permitía proporcionar la ubicación de una parada de transporte mediante una dirección postal en los campos stop_street, stop_city, stop_region, stop_postcode y stop_country. Ahora las ubicaciones de paradas deben proporcionarse mediante stop_lat para la latitud y stop_lon para la longitud, las cuales son más útiles para la mayoría de las aplicaciones.
  • Adición del tipo de vehículo funicular en el campo route_type en routes.txt.
  • Consulta el resumen entrada de blog de Tiempo entre trayectos original de los cambios.

29 de noviembre de 2006

  • Se agregó asistencia para información de la forma del trayecto a través de shapes.txt.
  • Se aclaró la definición de stop_sequence.
  • Se marcó a pickup_type y drop_off_type como opcionales.

31 de octubre de 2006

  • Se agregó asistencia para información tarifaria.
  • Se eliminaron las fechas de los nombres de archivos individuales.
  • Se cambiaron las definiciones del valor de route_type.
  • Se permitió la publicación de muchos archivos de feeds al mismo tiempo, siempre que sus períodos servicio no se superpusieran.
  • Se corrigió block_id en trips.txt de modo que se marcara correctamente como Opcional.
  • Se observó que los encabezados de columna deben estar incluidos.

29 de septiembre de 2006

  • Modificación menor para corregir un par de errores en los ejemplos.

25 de septiembre de 2006

  • Versión inicial.