Como datos "técnicos" se pueden incluir en la página de GTFS, y las informaciones importantes son: contacto, período de validez, versión. Crear un "card" y jalar la información desde la base de datos con GTFS.

Actualmente el sitio utiliza colores genéricos de Bootstrap (primary, secondary, success, danger, warning, info...). Hay que crear otros como bg-sangabriel y text-sangabriel, y bg-acosta y text-acosta con los colores asignados a cada ruta en GTFS, para dar acentos en el diseño de cada página.

Mucha gente prefiere compartir el horario o tenerlo para consulta como una foto (en lugar de visitar la página, quizá por consideración de consumo de datos, o lo que sea), así que sería buena poner esa versión a disposición también. Hay que diseñarla y/o generarla a partir de los datos con, quizá, LaTeX o alguna otra forma de transcripción.

Como aquí: https://observablehq.com/@d3/streamgraph-transitions

Evaluar opciones de estadísticas de uso para el sitio e incorporar la herramienta.

El ascenso y descenso es notable en estas rutas. Se puede representar con un gráfico de altimetría (y con las herramientas de visualización de JavaScript puede verse bonito). Para construirlo, se puede ampliar los datos de shapes.txt para incluir la altura (msnm) en cada coordenada.

Llevar el proyecto a Heroku de prueba. Documentar el proceso para hacerlo y habilitar credenciales para poder actualizarlo frecuentemente.

Importante para "proteger su sitio de fraude y abuso sin crear fricción" (Google), https://www.google.com/recaptcha/about/

La información disponible en páginas oficiales o incluso en medios es críptica:

Crucialmente, no hay información para el día específico en el que estamos, por ejemplo, un aviso que diga:

Hoy martes 8 de junio solo circulan las placas terminadas en números impares (1, 3, 5, 7, 9)

Que, es mi intuición, es la información puntual que la mayoría de la gente quiere. Incluso se puede traducir (es solo una frase) a N idiomas distintos, como ejercicio y porque puede ser importante para turistas.

Oportunidades: la información en La Nación, por ejemplo, no tiene ninguna sofisticación y podríamos mejorarla: https://www.nacion.com/el-pais/servicios/restriccion-vehicular-sanitaria-en-junio-2021/PQMQLN2AU5AZRFSEIC2DKKBKTU/story/

Algo relativamente sencillo: introducir la placa y que muestre en un calendario todos los días en que sí puede circular.

Con las tablas fare_attributes y fare_rules se puede determinar las tarifas según la parada y la zona de origen y destino. Es necesario crear un "widget" para que la gente haga esta consulta, según la ruta que está viendo. La plantilla de Bootstrap actual ofrece esta opción, por ejemplo: https://htmlstream.com/front/documentation/step-form.html pero se pueden buscar otras formas (ver referentes internacionales).

Con la tabla trips es posible saber cuántos viajes hay a la semana (actualmente hay unos 224). A modo de divulgación se puede poner un contador (https://htmlstream.com/front/documentation/counters.html) con los viajes semanales en la página de inicio, para información de usuarios (un "dato curioso"). Puede ampliarse a otros datos de la empresa.

Los feriados los horarios cambian, entonces debería haber un aviso (y algún mensaje por la celebración, de paso).

Crear una página para el error 404 y 50x, esta página preferiblemente estática sería el sink al cual redireccionar desde NGINX en caso de solicitar cualquier dirección que esté prohibida o que no exista como tal, actualmente en el modo DEBUG se muestra la página de Django con todo el trace pero en producción se muestra el not found por defecto del navegador que es bastante feo y puede confundir, la página debería llamarse 404.html y 50x.html y estar en la raíz de el directorio de estáticos, no necesariamente tiene que ser estática pero si lo fuera sería mejor porque podría funcionar inclusive antes de preguntarle al WSGI

Conectar con alguna base de datos atmosféricos y suministrar, por ejemplo, temperatura + precipitación actuales + pronóstico en las terminales.

Esta es una explicación de la implementación con un API de OpenWeatherMap: explicado por DigitalOcean.

Para hacer coincidir con GTFS apropiadamente es mejor tener ese nombre, por un asunto de consistencia interna. Sin embargo, cambiar el nombre a un modelo en Django es complicado, con algunas instrucciones aquí: https://stackoverflow.com/questions/25091130/django-migration-strategy-for-renaming-a-model-and-relationship-fields

Los horarios se obtienen de una inspección de rutas, viajes, las paradas y tiempos de las paradas, pero luego resulta simplemente en una tabla, que no cambia hasta que no se haga un cambio en GTFS (que sucede pocas veces al año).

Debería hacerse una sola ejecución y guardarse el resultado en una tabla de la base de datos de Django (creadas para este fin) y cargar la página desde ahí, generando el mismo "contexto" con el que ya trabaja la plantilla ruta.html. Posiblemente la tabla generada se sube como un "fixture" con python manage.py loaddata horarios_sangabriel.json, por ejemplo.

Sería importante automatizar este proceso de creación cuando se actualiza el GTFS.

Para crear un mayor contraste con algunos elementos, y para aprovechar que las "alertas" tienen transparencia, crear y aplicar una imagen de fondo tenue, en escala de grises para darle más "vistosidad" al sitio.

Algo así como https://web.dev/ para analizar cómo mejorar el sitio.

La barra horizontal de navegación en la parte de arriba de la página en su forma para desktop, originalmente viene con la siguiente clase de css.

.header-sticky-top-lg {
    position: fixed;
    bottom: auto;
    top: 0;
}

la position de tipo fixed no introduce un área en el documento, al igual que el absolute no se posiciona entre los otros elementos, lo que hace que todos los demás elementos ignoren su existencia.

el siguiente elemento en el documento es el main este elemento empieza desde arriba de la página, se traslapa con el topbar porque lo ignora y se muestra por debajo del esta barra. Para evitar esto el creador del tema introdujo un espacio vertical al inicio de main igual en alto al de la barra, esto normalmente no se hace así pero el diseñador lo hizo porque él quería que el tema tuviera un efecto en el que la barra se desaparece y aparece conforme se hace scroll hacia abajo o hacia arriba.

Actualmente el efecto ha dejado de funcionar o está desactivado, de dejarlo así entonces ya no tendría sentido mantener el fixed, para evitar tener que dejar ese espacio vacío en main lo mejor sería usar sticky el cual SI posiciona en el documento, obligando a los demás elementos a ordenarse respetando el área de la barra. para esto se podría hacer con la siguiente clase:

.custom-header-sticky-top-lg {
    position: sticky;
    bottom: auto;
    top: 0;
}

En la página de cada ruta, implementar el Scroll Nav para que sea más suave la transición cuando los usuarios van a buscar una sección más abajo: https://themes.getbootstrap.com/preview/?theme_id=4231

Nuevo documento de presentación del proyecto, que tiene que ser bien explicado y diagramado para el lanzamiento del sitio (y posible visitas al repositorio de personas interesadas).

Puede incluir, al menos, las siguientes secciones (algunas de ellas obtenidas del sitio mismo):

• Presentación (hecho por el TCU, etc.)
• Tecnologías
• Agradecimientos
• Participantes
• GTFS

Actualizar metadatos (como la descripción) y metaetiquetas. Referencias: https://developers.google.com/search/docs/advanced/crawling/special-tags?hl=es y https://www.wordstream.com/meta-description

Actualmente, el sitio muestra los cumpleañeros del mes, una característica muy propia de esa página. Para no romper con esa costumbre, podemos hacer una especie de "widget" con los cumpleañeros del mes en la sección /empresa/personal.

En https://htmlstream.com/front/documentation/leaflet.html está un mapa con el estilo de la plantilla usada. ¿Será posible adaptarlo para incluir el mapa con las trayectorias? Evaluar si tiene alguna ventaja más allá de lo puramente estético (que podría ser suficiente, si fuera fácil adaptarlo).