Objetivo

Permitir que o usuário (FE) pesquise no app pelo nome da estação (stop_name), para isso precisamos filtar por stop_name o end_point stops.

No front, a atual busca é disparada quando a subtring atinge 4 caracteres.
Limitar a quantidade de resultados (10 resultados).

• Trigger a partir do commit na branch main

Motivo

Versionar é sempre melhor para mapear o projeto ao longo do tempo.

Como será feito

Resumo

• Versão MAJOR (e.g. 1.0.0) será a mesma que o frontend (app) pois eles dependem entre si.

• Versão MINOR (e.g. 1.1.0) para qualquer recurso novo ou alterado que seja retrocompatível.

• Versão PATCH (e.g. 1.1.1) para qualquer tipo de correção de erros ou alteração de README e arquivos sem importância.

Detalhes

MAJOR

• Planejamento prévio entre ambos projetos sobre como será a nova versão, qual o objetivo e o que deve mudar de impactante.

  A nova versão será criada a partir da versão atual, e mudanças serão aplicadas como MINOR ou PATCH.

• Usar o primeiro commit na branch principal que atende os requisitos para a nova versão MAJOR do frontend.

  A data do commit deve ser a mais próxima possível da publicação da MAJOR do frontend.

MINOR

• Adicionar, alterar ou remover qualquer funcionalidade dentro do contexto e retrocompatível com a MAJOR.

PATCH

• Quaisquer correções de erros
• Qualquer alteração em documentação em geral, como jupyter, README.

  Normalmente essas alterações são enviadas junto com atualizações MAJOR ou MINOR.

Tarefas

• Mapear versão 2.0

  • Concluído em 07/02/2023

    O commit b4378b2 staging > main - mudança no modelo, criação de ambiente local e endpoints é o commit mais antigo que o frontend v2.0 consegue utilizar. Pois ele cria a URI gtfs/<endpoint>.

• Mapear versões 2.x.x

  • Concluído em 15/02/2023

    O commit 9dcf808 [feat] filtro shape_id em gtfs/shapes > main é o único commit mais atual da branch main.

• Lançar Releases 2.x.x

• Mapear versões 1.x.x

  Serve para entender a lógica do projeto desde a gestão anterior.

  • (16/02/2022) As versões foram mapeadas. Foi decidido com a equipe que é interessante usar, porém a versão começaria de 1.1.0. (veja o comentário)

    Portanto o mapeamento será revisado, e subversões de main terão descrição mais detalhada sobre o que mudou.

Referências:

• https://semver.org/
• https://medium.com/fiverr-engineering/major-minor-patch-a5298e2e1798

Lógica usada

Estação

• No BRT todas as estações são stops (stops pai) e devem ter um stop_code.
• Toda estação também é um stop pai, portanto não possui platform_code.
• Cada estação possui pelo menos 2 plataformas, que também são stops (stops filho).

Plataforma

• Toda plataforma é um stop filho, portanto possui platform_code igual o stop_id de sua estação (stop pai).

Filtragem em stop_times

• Se o stop for stop pai, mostra as trips de seus stops filho.
• Caso contrário, mostra as trips de todos os stops filho

Tarefas

• Subir PR
• Aprovar PR de feat para dev
• Verificar se essa feature ainda é necessária.
• Mapear features em dev e discutir se compensa juntar a branch dev ou apenas uma branch com essas features.
• Subir PR para dev - será nosso staging no momento (01/03/2023)

Notas para consultar:

• Renomear branch release/2.2.0-gtfs-transolimpica na issue #142
• Criar release/2.2.0-stop_id-parent-stoptimes de branch release/2.2.0-gtfs-transolimpica
• Cherry pick dessa feature em feat/stop_id-parent-stoptimes
• Revisar PR para dar merge em main
• Aprovar PR
• Merge em staging e dev

• Montar infra
• Desenhar user-flow / telas

Situação

29/03/2024

O preditor está retornando zero resultados no dia de hoje, sendo que há serviços de exceção (calendar_dates) que deveriam aparecer.

Foi feita uma correção na query do banco seguindo a lógica de negócio (requisito da geração de predição)

08/01/2024

O endpoint do preditor começou a retornar 0 resultados.

Possíveis causas:

• ❌ Endpoint externo do realtime está fora do ar
  • Os dados estão sim no ar.
• ❌ Endpoint externo do realtime parou de atualizar os dados
  • Os dados estão sim atualizados.
• ✅ Problema com o banco de dados
  • Os service_id estão desatualizados (2023 ao invés de 2024), portanto o preditor não teve dados atuais para gerar o resutado.
• ❌ Endpoint externo do realtime exibe veículos com previsão longa demais, por isso estão sendo ignorados.
  • Os dados são recentes

Tarefas

• Descobrir o problema
• Testar novo GTFS em homologação
• Aplicar GTFS em produção
• Fazer API mostrar possíveis causas da resposta vir zerada no Preditor
• Criar endpoint para teste

Contexto

Inserimos manualmente em fixtures todas as linhas, pontos, sequências, etc. Queremos fazer essa relação atrelada diretamente à API do SIGMOB para manter as informações mais recentes.

Algoritmo

Semanal:

• Puxa informações do sigmob
• Remove serviços SV e SN
• Calcula linhas operantes:
  • Linha com operação abaixo de 20% do determinado. (Pegar a maior hora cheia do dia para fins desse cálculo)
  • Últimos 5 dias úteis com a mesma situação
• Atualiza as fixtures (json) no Django

• Endpoints do SIGMOB (Coversar com Bernardo) @joaoc
  • Info dos pontos [id_ponto]
  • Ponto -> List(Linha)
  • Info das linhas [id_linha/servico/itinerário]
• Quais endpoints? Esperar front final
• Desenvolver enpoints

https://drive.google.com/file/d/1OWfMyi9rRtis8m2q3rsUdDeY-i-k5GiN/view?usp=sharing

Objetivo

Filtrar todos os endpoints do gtfs do modal desejado com base no route_type (campo original de routes)
Com adição de novos modais os dados tem origem diferentes. O filtro por route_type permite a diferenciação por modal em cada entidade.

Lista de ids de route_type:

• Ônibus executivo: 200
• SPPO: 700
• BRT: 702
• STPL: 704
• STPC: 1501

Endpoints para adicionar filtro:

• agency
• stop_times
• routes
• trips
• shapes
• stops
• shapes_with_stops

Objetivo

CI de staging só faz o build quando o commit é feito em release/staging. A expectativa é o deploy ocorra a partir de commits em qualque branch release/*

Contexto

Utilizar os 3 últimos dias do mesmo dia da semana para calcular (Hoje é sexta, então tem que verificar o comportamento das últimas 3 sexta-feiras:

Terão as seguintes categorias:

• Manhã (5h - 11h) - 7 faixas horárias
• Tarde / Noite(14h - 20h) - 7 faixas horárias
• Hora útil (Manhã + Tarde/Noite)
• Noturno (22h - 4h) - 7 faixas horárias
• 24h (Diurno + Noturno)
• Sem previsão de funcionamento

Deverá realizar o levantamento de operação dos últimos 3 dias úteis e categorizar essa linha considerando essas faixas horárias. A linha deve apresentar pelo menos 20% da frota determinada em pelo menos mais de 4 faixas horárias do período das categorias acima para receber o título.

Caso a linha não apresente operação que se enquadre na regra acima ela receberá a categoria "Sem previsão"

Resultado esperado

trip.json:

{
        "model": "pontos.trip",
        "pk": "2200002601020101",
        "fields": {
            "route": "22000026010",
            "headsign": "Vidigal",
            "via": "",
            "version": "01",
            "direction": 2,
            "operation_time": "Manhã"
        }

• Adicionar instruções no README

Objetivo

• Para fazer as predições o algoritimo do preditor precisa de informações de stop_times, shapes e routes, o endpoint shapes_with_stops de servir essas informações.

trip_id * 

stop_id * 
stop_name
stop_lat * 
stop_long * 
stop_sequence

shape_dist_traveled *  
route_id * 
route_short_name * 
route_long_name

previous_stop_id  * 
previous_stop_name
next_stop_id *
next_stop_name

Objetivo

Subir dados da Transolímpica em dev para teste e validação do FE

• Preencher stop_codes
• Adicionar dados no django

Motivo

Filtrar por stops filho que são do BRT na Alvorada

Stops filho SPPO da Alvorada têm o mesmo stop_id que do BRT, mas sem QRCode cadastrado.

Tarefas

• Fazer RR
• Aprovar PR

• Revisar IDs do SIGMOB #39
• Adicionar informações + 2 pontos BRS -> aguardado envio dos IDs

Exemplo de uma API bonitona: https://rj-smtr.github.io/sigmob-api-docs/

Objetivo

Informar todas as linhas que passam entre 2 pontos, incluindo integrações

Ideias:

• Networkx: https://github.com/networkx/networkx

A principio da parar usar um modulo tipo networkx no python para rodar, mas podemos estudar outros.

Comportamento:

• Input: codigo do pt de origem
• Output: lista de todos os demais pts que podem ser acessados + atributo do pt (codigo do servico que vai da origem para o destino)

Requisitos

1. Deve obter os dados da API do SPPO com sucesso
2. Fazer Join com SPPO do bigquery com as colunas extras
3. Retornar o resultado para o front

Issue pai: #134

Tarefas

• feat: populate_db tira duplicatas pela ordem alfabética das pastas

Desenvolver em pipelines

Objetivo

O preditor foi construido usa dados estáticos, precisamos atualizar as fontes de dados.

• Buscar dados de GPS
• Buscar dados de predição
• Cruzar com gtfs

Desenho da arquitetura: https://miro.com/app/board/o9J_lqIY7Eg=/

Tarefas

• Adaptar e implantar preditor v1 (simplificado) #144 na branch feat/predictor
• Fazer PR para dev
• Subir para stag
• 🐛 Corrigir bug: evitar sobrecarga de requisições para api realtime (?)

  Será usado o gateway Konga para armazenar o endpoint em cache e só requisitar a cada 30s

• Usar env no k8s para poder remover a variável
• Subir para prod

Tarefas

Finalizar antes de lançar o app

• Verificar se precisa aplicar mudanças críticas para o app funcionar corretamente.

  • Comparar staging com main. Se estiver atrás da main, rebase.
    • (23/02/2022) O último commit de main é merge do último commit de staging: 9dcf808
  • Verificar mudanças relevantes

    Mudanças em branches como dev, feat e hotfix. Além de coisas necessárias para o novo GTFS.

• Corrigir certificado de staging

Motivo

• Permitir o usuário enviar uma avaliação dos dados GTFS do BRT
• É importante equipe saber se os dados informados estão atendendo os usuários.

Tarefas

• Lançar feature em dev e staging
• 🚧(bloqueio) Corrigir tipagem do IP para varchar

  Não é o ideal (IPField), mas torna possível receber ips, corretos ou não.

• Adicionar autenticação para fazer POST
• (não urgente) Testar o ip que não é obtido do usuário, mas sim do pod.

  É bom testar num k8s local e ver se funciona.

Campos usados

Tabela FeedbackBRT:

Objetivo

API realtime será atualizada, precisamos atualizar o codigo e verificar se os trexos get_trip_id e get_true_tripid precisam ser mantidos.

Situação

Revisando o que deve acontecer:

• Se a busca é pelo stop_id, deve retornar de stop_times apenas os itens que contém aquele stop_id
• Se a busca é pelo trip_id, deve retornar de stop_times apenas os itens que contém aquele trip_id

Nesses casos já existe um filtro para isso.

O que deve ser implementado:

• Remover stops desnecessários, que contenham conteúdo igual () exceto apenas o trip_id
• ⚠️ Precisa avaliar se em algum lugar isso está sendo utilizado no preditor, para não quebrar nada.

Exemplos

Exemplo do caso 1: no ponto 1K84 passam 8 serviços.

https://mobilidade.rio/1k84 -> nessa tela, a busca na API deveria retornar apenas 8 itens, mas hj retorna 194 (186 são inúteis), e demora mts segundos para carregar a tela por conta disso.

• chamada da API: https://api.mobilidade.rio/gtfs/stop_times/?stop_id=2028O00023C0

Exemplo do caso 2: já nessa nela, o retorno da API está certo ✅

A busca é pela trip, que retorna todos os pontos da trip (44 pontos). para facilitar o FE aqui, vale ordenar o retorno pelo stop_sequence

• chamada da API: https://api.mobilidade.rio/gtfs/stop_times/?page=3&trip_id=26a61192-414b-4fc4-959d-d37c871c7ebd

Objetivo

Com base na frequencies, construir uma tabela de horários de partida de cada trip programada

O endpoint gtfs/frequencies possui essa informação mas não fornece uma tabela de horários. Em frequencies temos, Para um período do dia (14:00 - 15:00) o intervalo esperado de saídas em segundos (1600). Esse end point, deve transformar a informação de frequencies em um quadro horário.

{
	"results": [{
		"id": 5634,
		"trip_id": "039929bd-981f-4162-a0e8-87cab26439b5",
		"saida_planejada": "20:24:00",
		"exact_times": 0
	}, {
		"id": 5635,
		"trip_id": "039929bd-981f-4162-a0e8-87cab26439b5",
		"saida_planejada": "20:34:00",
		"exact_times": 0
	}, {
		"id": 5636,
		"trip_id": "039929bd-981f-4162-a0e8-87cab26439b5",
		"saida_planejada": "20:44:00",
		"exact_times": 1
	}]
}

Otimizar tempo de consulta de dados

Objetivo

O modelo de dados do preditor pode perder precisão com o passar do tempo, precisamos atualiza-lo periódicamente. Precisamos integrar a dinamica de armazenamento/inicialização do modelo na api ao pipeline de geração do mesmo.

Objetivo:

Com a inclusão do BRT existem estações que possuem mais de uma plataforma para embarque cujo location_type é 1, quando pesquisamos o stop_id em stop_times nesse caso o retorno vazio por tratar-se de uma parent station.

Quando o location_type for 1 precisamos incluir no retorno as os dados cujo parent_station possui id igual ao id buscado.

$ python manage.py loaddata fixtures/trip.json
django.db.utils.DataError: Problem installing fixture '/app/fixtures/trip.json': Could not load pontos.Trip(pk=4004018101030101): value too long for type character varying(50)

fixtures/trip.json:

    {
        "model": "pontos.trip",
        "pk": "4004018101030101",
        "fields": {
            "route": "40040181010",
            "headsign": "Estrada do Sacarr\u00e3o \u0097 Recreio dos Bandeirantes (Circular)",
            "via": "Estrada Vereador Alceu de Carvalho",
            "version": "01",
            "direction": 3
        }

models.py (no cluster):

class Trip (models.Model):
    id = models.CharField(max_length=50, primary_key=True)
    route = models.ForeignKey(Route, on_delete=models.CASCADE)
    headsign = models.CharField(max_length=250)
    via = models.CharField(max_length=50, blank=True, null=True)
    version = models.CharField(max_length=50, blank=True, null=True)
    direction = models.IntegerField(default=0)

    def __str__(self):
        return f"Viagem {self.route} - {self.headsign}"

Objetivo

Validar os campos do GTFS BRT que estão em staging em 3 categorias de validação:

1. Campos necessários para o Front-end.
2. Campos com critérios especiais, definidos pela SMTR (stop pai e filho)
3. Utilizar validação GTFS definida no Google Transit (e gtfs.org).

Justificativa

O principal motivo é garantir que os dados foram validados da melhor forma possível. Caso ocorra algum bloqueio, esta issue será de grande ajuda.

Observações

• Subiu-se em 27/02/2023 os GTFS BRT 2023-02-27 11-41 e SPPO 2023-02-14 17-19
• 🚧 (bloqueio) SPPO.stoptimes não subiu pois arrival_time teve problema com tipo no banco.

Dependências

• Corrigir dados GTFS

Tarefas

• Resolver bloqueio sobre subida do SPPO

  • Corrigir populate_db para não abortar ao subir

  Corrigido em 06/03/2023, 20:30

  • Mudar tipagem de todos arrival_time para duration

  Corrigido em 06/03/2023, 20:30

• Validar campos com critérios GTFS

  • ❌ (06/02/2023) Validação falhou. (validação, tentativa 1)

  • (08/02/2023) Após conversar com @gsperim e @gbragaalves os critérios de validação foram alterados. Será feita uma nova validação (reunião com @gbragaalves)

  • ✅ (10/02/2023) Os dados passaram nos critérios GTFS com sucesso!

• Validar campos com critérios da SMTR

  • ❌ (10/02/2023) A validação com critérios da SMTR falhou. Outras possibilidades foram testadas para adiantar a solução deste problema. (validação, tentativa 2)

  • (14/02/2023) Após conversar com @gsperim e @gbragaalves foi decidido que os erros serão corrigidos por @gbragaalves e responsáveis. GTFS gerado em 24/02/2023

  • ❌ (24/02/2023) A validação com critérios da SMTR falhou com menos erros. (validação, tentativa 3)

  • ❌ (02/03/2023) A validação com critérios da SMTR falhou com menos erros. (validação, tentativa 4)

• Validar campos necessários para o frontend

  • ❌ (10/02/2023) A validação com critérios do frontend falhou. Apenas um campo falhou. Será necessário discutir esse problema com o front e o resopnsável pelo gtfs. (validação, tentativa 2)

  • ❌ (09/03/2023) Os stops filho com problemas são da transbrasil, portanto seriam ignorados por enquanto.

  • (13/02/2023) Após conversar com @Gabriel0109, entendeu-se que o frontend consegue lidar com stops sem stop_code, ignorando-os. O front (v2.1.0) não pesquisa esses stops, nem pelo nome.

  • ✅ (14/02/2023) O stop_code, apesar de desejável, será opcional assim como nos critérios GTFS. O front automaticamente ignora os stops sem stop_code. (reunião com @Gabriel0109; reunião com @gbragaalves)

• Definir se é necessário informação do corredor. Caso sim, como obter?

  Ex: Transcarioca, Transolímpica

  • (14/02/2023) Em stop_code terá o prefixo TC para trancarioca e TO para transolímpica e assim por diante. (reunião com @gbragaalves)

Verificações

1. Campos necessários para o frontend (v2.1.0)

Legenda - Comparando com o Google Transit:

• obrigatório
• obrigatório com critérios*
• opcional

Todos os campos a seguir são obrigatórios para o frontend.

stops:

• stop_code: Home:65, InfoCard:22, GetCode:30, GetShape:20
• stop_lat*, stop_lon*: Home:66,102, GetShape:21
• stop_name*: InfoCard:23

stop_times:

• stop_id: GetTheme:20
• trip_id: GetTrips:41

trips:

• trip_id: GetTrips:39

shapes:

• shape_id, shape_pt_lat, shape_pt_lon: getShape:26,44

2. Campos com critérios SMTR:

Legenda - Comparando com o Google Transit:

• obrigatório
• obrigatório com critérios*
• opcional

stops:

• Todos e somente os stop pai deve ter stop_code
• Todos e somente os stop filho devem ter stop_desc.
• Todos e somente os stop filho devem ter platform_code.
  • Valores permitidos: 1,2,3,4.

3. Campos com critérios GTFS:

Os critérios dos demais campos seguem o modelo do Google Transit e gtfs.org.

stops:

• stop_id: Obrigatório
• stop_name, stop_lat, stop_lon: Obrigatório se location_type = 0,1,2
• zone_id: Obrigatório se existir fare_tules.txt
• parent_station: Obrigatório se location_type = 2,3,4
• stop_code, stop_desc, stop_url, location_type, stop_timezone, wheelchair_boarding, level_id, platform_code: Opcional

trips:

• route_id, service_id, trip_id: Obrigatório
• shape_id Obrigatório se a trip possuir um shape em shapes.txt

  (10/02/2022) A validação adotada verifica se existem stops não usados por nenhuma trip, caso sim, é obrigatório.

• trip_headsign, trip_short_name, direction_id, block_id, wheelchair_accessible, bikes_allowed: Opcional

shapes:

• shape_id, shape_pt_lat, shape_pt_lon, shape_pt_sequence: Obrigatório
• shape_dist_traveled: Opcional

routes:

• route_id: Obrigatório
• route_type: Obrigatório

  Será sempre exibido nos resultados pois é muito improtante para saber se é BRT, ônibus, etc.

• route_short_name: Obrigatório se não tiver route_long_name com nome distinguível, e se a agência de transportes ou a SMTR tiver identificadores para usar nesta linha.
• route_long_name: Obrigatório se não tiver route_short_name.

  Será obrigatório ter route_short_name ou route_long_name; será opcional ter ambos.

• agency_id: Obrigatório se houver mais de uma agência em agency.txt.
• route_desc, route_url, route_color, route_text_color, route_sort_order, continuous_pickup, continuous_drop_off: Opcional

stop_times:

• trip_id, stop_id, stop_sequence: Obrigatório
• arrival_time: Obrigatório se o stop_sequence de sua trip é o primeiro ou o último; ou se timepoint = 1.
• departure_time: Obrigatório se timepoint = 1.
• stop_headsign, pickup_type, drop_off_type, continuous_pickup, continuous_drop_off, shape_dist_traveled, timepoint: Opcional

Validações opcionais

Apenas para confirmar a coerência dos dados, não há pressa para fazer isso.

• stop não pode ser pai e filho ao mesmo tempo (ter e ser parent_station).
• trips.shape_id é obrigatório se a trip possuir shape em shapes.txt

  A condicional usada é se existem shapes não usados por trips.

Onde

• Stop filho é todo stop que possua parent_station de outro stop.
• Stop pai é todo stop que não possua parent_station e seu stop_id seja parent_station de outro stop.

Notas:

Após validar, criar um comentário com os critérios usados e o resultado.

Caso os critérios mudem, atualize este comentário.

Referências:

• Caso o Google Transit fique confuso de ler - gtfs.org

• 1a versão:
  • Usar a mesma metodologia de cálculo das frequencies no GTFS

Notable changes (2.4.0)

• 10e2f1c, 01eea61, 77ce880:

  • 🎁 Novos filtros em /frequencies: trip_short_name, direction_id e service_id
  • 🎁 Novos filtros em /trips: trip_short_name, direction_id e service_id - para fins de debug.
  • 🎁Por padrão, /frequencies exibe apenas trips não redundantes de stop_times. Para desativar esse filtro, utilize o parâmetro show_all=true
  • 🐞 stop_times oculta por padrão trips redundantes filtrando também por shape_id, e não apenas por trip_short_name, direction_id e service_id.
  • 🐞 A query usada em stop_times para filtrar trips redundantes foi otimizada.
  • 🐞 O valor de trip_id em frequencies exibe um json com seus atributos, não mais uma URL.

• eb12098:

  • 📝 README refatorado.

Contributors

• @yxuo

Faz sentido adicionar na release (dev-2.4.1):

• 41a4f6b:
  • 🧹 Remover e ignorar arquivos de desenvolvimento local.
  • 📝 README refatorado.
• d13c536:
  • ♻️ Limpar código.

Hoje a pagina nao retorna nenhum dado na home, a expectativa era ter uma lista dos endpoints da API

Objetivo

Preditor consome os dados de shapeWithStops de um arquivo, precisamos entregar esses dados por um endpoint na aplicação e eliminar campos que não são necessários.

Instruções

• em predictor/utils.py:61 (capture_trip_stops), será trocado o shapes_wish_stops.csv pelo uso do endpoint.
  Veja linha 65-66

Objetivo

• Tirar tudo que tiver SN em route_short_name

O que foi feito

• Criar branch para hotfix de populate_db
• Dar commit em dev-local
• Criar ramo feat/populate_sb-remove_cols_containing a partir de dev
• Adicionar filtro remove_cols_containing, sem incluir outras funcionalidades
• Testar novo código e comprarar com o antigo
• Subir alterações
• Enviar PR em dev
• Validar PR

Como usar

Em scripts\populate_db\settings.json, é possível ignorar qualquer coluna se o valor conter o subtexto.

No exemplo abaixo, o subtexto será teste:

{
    "remove_cols_containing": {
        "tabela1": {
            "coluna1": [
                "teste"
            ]
        }
    },
}

Antes:

    tabela1
    ---
    coluna1     coluna2
-   teste1      a       
-   teste2      b       
    maçã        c
    banana      d

Depois:

tabela1
---
coluna1     coluna2
maçã        c
banana      d

Motivo

Neste momento as features parecem ok para lançar o app BRT.

O app deve ser lançado em 06/02/2023

Tarefas

• Fazer PR para release 2.2

  Tarefa pulada pois a lógica era feature -> PR dev -> release.

• Avaliar, com supervião, principalmente as alterações em cd_dev e cd_stag.

  Tarefa pulada pois já foi feita uma reunião com @gsperim sobre isso.

Bloqueios

• Conflito do merge em cd_stag.yml

  Branch dev (L67):

      # if: github.ref == 'refs/heads/dev'

  Branch main e staging (L66):

      if: github.ref == 'refs/heads/release/staging'

  • (28/02/2022) Solução adotada: usar arquivo em dev.

• Decidir se aplica as alterações de dev em PRs por feature e hotfix.

  A ideia é fazer PR de features em dev, de dev para release (nosso staging), e de release para main.

Preencher abaixo:

O que já foi feito?

O que está em andamento? (+ bloqueios)

1. Endpoint da tabela de predição no Django - feat/predictor-v2

• Corrigir: Ao gerar predição, arrival_time sempre é NaN

2. Cronjob para gerar tabela de predição - feat/predictor-v2

• Criar um método para atualizar a cada 20 segundos.
• Testar rotina funcionando em dev

=> https://api.mobilidade.rio/

• Add descricoes
• Add parametros possiveis em cada endpoint