Probar un feed estático en una vista previa privada

Una vez que hayas subido un feed de especificación de feeds general para el transporte público (GTFS) válido en el panel de control de Transit Partners, podrás activar una vista previa privada para probar la programación y las rutas del feed en un entorno de staging antes de lanzarlo públicamente.

Te recomendamos que pruebes los datos de la vista previa con personas que conozcan tu servicio de transporte público, como los representantes del servicio de asistencia.

Previsualizar tus datos de GTFS en Google Maps

1. Inicia sesión en la cuenta de Google asociada a tu panel de control de Transit Partners. (Crear una cuenta de Google.)
2. Visita Google Maps.
3. Prueba varias consultas en tu zona (por ejemplo, ubicaciones de estaciones, horarios y formas de ruta).

Si hay varias personas encargadas de probar la vista previa, tal vez quieras crear una cuenta genérica de Gmail (como <agency_name.gt>@gmail.com) para que estos usuarios puedan compartirla, o bien asociar una cuenta de Google a tu alias de correo electrónico interno de tu grupo.

Probar los feeds

Después de acceder al entorno de staging de la vista previa privada, puedes consultar los datos del feed directamente en la pestaña "Cómo llegar" de Google Transit.

Cada consulta de "Cómo llegar" generará varias opciones de trayecto, etiquetadas como "Información confidencial de Google", en rojo, junto a los resultados. Estas opciones solo usan los datos de tu feed.

Puede que veas opciones sin la etiqueta "Información confidencial de Google"; estas opciones provienen de los datos activos de otros feeds.

Cada vez que modifiques el feed, tendrás que esperar unos días para que se actualicen los datos de la vista previa. Por lo tanto, es importante que corrijas tantos problemas como sea posible.

Además de los casos de prueba normales, también debes comprobar tu vista previa privada para asegurarte de que:

• las formas de ruta de los trayectos coincidan con las carreteras en Google Maps.

• el tiempo total de los trayectos sea lógico (por ejemplo, que el autobús no se desplace a una velocidad demasiado rápida ni demasiado lenta)

• los trayectos se prueben tanto entre semana como el fin de semana, usando el menú desplegable Salir ahora

• los transbordos se hagan en los lugares adecuados

Probar diferentes opciones de rutas

El planificador de trayectos de Google está diseñado para mostrar varias opciones para cada ruta solicitada. Sin embargo, puede que sus resultados difieran de los de otros planificadores de trayectos. El algoritmo de Google intenta buscar el trayecto más rápido al destino y penaliza los transbordos y los recorridos a pie.

Si encuentras una consulta en la que tus datos muestren una opción mucho mejor que la que ofrece el planificador de trayectos de Google, avisa al equipo de asistencia para partners de Google Transit. Al informar de problemas a Google, incluye el enlace al trayecto haciendo clic en el botón , en la esquina superior izquierda de Google Maps, y seleccionando "Compartir o insertar el mapa". Dado que no estamos familiarizados con la zona local, incluye información lo más detallada posible.

Ten en cuenta que los datos de rutas que ya están publicados se muestran como primera opción, aunque una de las rutas de la vista previa sea más adecuada.

Probar trayectos con transbordos

Cuando pruebes la vista previa del feed, verifica que los transbordos entre trayectos sean razonables. Prueba a hacer algunas consultas que requieran transbordos en los principales puntos de transbordo de tu red y observa si los resultados son lógicos.

Cuando pruebes los transbordos, debes tener en cuenta lo siguiente:

• Nuestro algoritmo de rutas tiene en cuenta las oportunidades de transbordo en la misma parada y aquellas para las que hay que caminar de una parada a otra.

• En ambos casos, el algoritmo calcula un tiempo mínimo de transbordo entre la llegada y la salida (incluido un búfer de seguridad), así como los desplazamientos a pie. Puede que debas adaptar nuestras estimaciones a tus datos concretos.

Comprueba también los tiempos de transbordo en las principales estaciones de transbordo, donde se cruzan o finalizan varias líneas, observando específicamente la diferencia entre las horas de llegada y de salida. Si detectas que el tiempo de transbordo mínimo estimado es demasiado bajo (caso poco frecuente) o demasiado alto, puedes solucionarlo proporcionando un archivo transfers.txt (tal y como se explica en la especificación GTFS) que describa las oportunidades de transbordo de tu red.

Probar el feed con consultas aleatorias

Otra manera de probar el feed es usar las consultas aleatorias que se encuentran en tu informe de validación de GTFS. La pestaña Queries (Consultas) del informe de validación incluye consultas generadas de forma aleatoria sobre indicaciones de Google Maps entre pares de paradas de tu feed. Usa estas consultas para probar y verificar los resultados de rutas de transporte público de tu feed; así mejorarás tus propias pruebas.

Revisión con control de calidad

Cuando hayas solucionado todas las advertencias y la versión de la vista previa de tu feed GTFS sea adecuada, ponte en contacto con tu equipo de Google, que realizará una revisión con control de calidad del feed. Te informaremos de los posibles problemas que detectemos en tu feed y colaboraremos contigo para solucionarlos.

Antes de lanzar los feeds GTFS, Google requiere una revisión y una aprobación de lanzamiento finales.

Prácticas recomendadas para probar la vista previa privada

Comprobar las rutas en la vista previa de Google Maps

Cuando hayas verificado las consultas aleatorias, planea manualmente los viajes en Maps usando las coordenadas geográficas de las paradas.

Generar un viaje aleatorio

Puedes generar un viaje de ejemplo que contenga tus datos de la pestaña Consultas del informe de validación.

Planifica un viaje

Antes de realizar pruebas manualmente, asegúrate de que has iniciado sesión con tu cuenta de Google en el panel de control de Transit Partners.

Para probar manualmente un viaje, sigue estos pasos:

1. Abre Maps.
2. Haz clic en Cómo llegar .
3. Haz clic en Transporte público .
4. Utiliza los valores de latitud y longitud de las paradas para planificar un viaje. Ten en cuenta lo siguiente:
   • Los nombres de las estaciones y las paradas no están disponibles en la vista previa.
   • No se ofrecen conexiones con servicios de autobús, tren y ferry de otras empresas de transporte público.
5. Prueba a hacer consultas con las opciones Salir ahora y Salir a las.

Después de planear el viaje

Los resultados de las rutas del trayecto aparecen sobre un fondo rosa claro. Esta información es confidencial y no se muestra a los usuarios finales.

Después de planear el viaje, comprueba los datos siguientes:

• Nombres corto y largo de la ruta
• Hora y fecha de la parada
• Nombre de la parada
• Duración del trayecto
• Formas (si se especifican)
• Nombre de la empresa
• URL de la empresa
• Número de teléfono de la empresa (si se especifica)  
• Información de la tarifa (si se especifica)
• URL de la tarifa

Asegúrate de que todas las entidades coincidan con la información incluida en tu sitio web y de que los usuarios finales las puedan reconocer.

Los resultados de la ruta son una representación visual de los campos mostrados a los usuarios finales.

Comprobar el feed GTFS

Pruebas preliminares

• Periodo de servicio: debe tener una duración de más de 28 días y menos de 3 años.
• Cobertura: debes ofrecer una cobertura completa. En caso de que ofrezcas cobertura limitada, debes notificárnoslo con una explicación válida en el formulario de la lista de comprobación.
• Advertencias de validación: comprueba y soluciona este tipo de advertencias que encontrarás en la pestaña Error del último informe de validación que se haya generado.

Pruebas detalladas (archivos GTFS)

• Agency.txt: la información de la agencia proporcionada es correcta y coincide con la de su sitio web.
  • Se recomienda indicar el número de teléfono de la empresa y las URLs de las tarifas para mejorar la experiencia de usuario.
• Calendar.txt: se incluyen todos los servicios con días de la semana activos.
• Calendar_dates.txt: 
  • Las fechas de excepción coinciden con el periodo de servicio definido en calendar.txt.
  • Se incluyen todas las fechas en que los servicios se ejecutan de manera diferente (reducidos o ampliados) respecto las fechas habituales (como los días festivos).
  • Si tus servicios no tienen excepciones, ignora la advertencia "El feed no tiene excepciones de fechas en el calendario".
• Routes.txt: 
  • Los nombres y los colores de las rutas coinciden con los que aparecen en el sitio web de la empresa, y los usuarios finales pueden reconocerlos.

  • Si se proporcionan las etiquetas route_short_name y route_long_name, los usuarios finales encontrarán route_short_name.

  • Las rutas no se dividen por dirección.
  • Las etiquetas Route_urls son específicas de las rutas o no se proporcionan.
• Trips.txt: 
  • Las etiquetas Trip_headsigns indican la dirección correcta del trayecto, y los usuarios finales pueden reconocerlas.
  • Las etiquetas Trip_headsigns no duplican los nombres de las rutas.
  • Las etiquetas Trip_headsigns solo se definen para las rutas lineales.
  • Las etiquetas Trip_short_names solo se definen para route_type: tren interurbano.
  • Los valores de nombre corto de viaje se definen únicamente para trenes interurbanos o de larga distancia.
• Stops.txt: 
  • Los nombres de las paradas parecen razonables y coinciden con la información que aparece en el sitio web de la empresa.
  • Los nombres de las paradas no incluyen códigos de parada stop_codes, excepto en Brasil.
  • En los nombres de las paradas se pueden usar abreviaturas, pero tienen que ser siempre las mismas.
  • Las ubicaciones de las paradas son precisas (en el lado correcto de la calzada y cerca de la acera).
  • Si se proporcionan Stop_codes, estarán disponibles en el sitio web de la empresa, y los usuarios finales deben poder reconocerlos.
  • Las URL de las paradas son exclusivas de cada una de ellas.
• Shapes.txt (opcional, pero muy recomendable): 
  • Las formas siguen con precisión las vías y las líneas ferroviarias.
  • Se proporcionan formas para todos los trayectos y en el archivo trips.txt se hace referencia a ellas.
  • Corrige cualquier advertencia de validación relacionada con el archivo shapes.txt.
• Stop_times.txt: 
  • Las horas de parada definidas en el feed deben estar disponibles en el sitio web, y los usuarios finales pueden reconocerlas.

  • Si se define, comprueba cómo se realiza el proceso de recoger y dejar pasajeros.

    No se admiten los atributos pickup_type, pickup_type 2 (se debe llamar a la empresa) y 3 (se debe coordinar con el conductor).
  • En el caso de las rutas circulares, se debe definir stop_headsign en cada parada.
• Feed_info.txt: 
  • El idioma del feed está definido en este archivo o en agency.txt.
  • Compara las fechas de inicio y finalización con los archivos de calendario.
• Advertencias de validación
  • No hay advertencias de que la parada está demasiado lejos de la forma.
  • No hay advertencias de que las paradas coinciden con la forma en el orden incorrecto.
  • No hay advertencias de que hay demasiadas paradas consecutivas con la misma hora.
  • No hay advertencias de que hay paradas de trayectos en la misma manzana que se solapan.
  • No hay advertencias de que faltan fechas del servicio.
  • Hay advertencias de que hay paradas en la zona horaria incorrecta.
  • Hay advertencias del contraste del color de la ruta.
  • Hay advertencias de que falta el tiempo de transbordo mínimo.
  • Hay advertencias de que el letrero de la parada es igual que el nombre de la parada.
  • Hay advertencias de que la ubicación del punto está demasiado cerca del origen (0,0).

Enviar la lista de comprobación de prelanzamiento

Cuando hayas comprobado que tu feed cumple las directrices anteriores y los resultados de las rutas en Google Maps te resulten satisfactorios, completa el formulario de la lista de comprobación de prelanzamiento. A continuación, el feed que envíes se someterá a un control analítico de calidad.