rj-smtr / mobilidade-rio-api Goto Github PK
View Code? Open in Web Editor NEW⚙️ API do web-app de mobilidade da SMTR
Home Page: http://api.mobilidade.rio
⚙️ API do web-app de mobilidade da SMTR
Home Page: http://api.mobilidade.rio
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).
main
Versionar é sempre melhor para mapear o projeto ao longo do tempo.
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.
MAJOR
A nova versão será criada a partir da versão atual, e mudanças serão aplicadas como MINOR ou PATCH.
A data do commit deve ser a mais próxima possível da publicação da MAJOR do frontend.
MINOR
PATCH
Normalmente essas alterações são enviadas junto com atualizações MAJOR ou MINOR.
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:
Estação
stop_code
.platform_code
.Plataforma
platform_code
igual o stop_id
de sua estação (stop pai).Filtragem em stop_times
dev
dev
e discutir se compensa juntar a branch dev
ou apenas uma branch com essas features.Notas para consultar:
release/2.2.0-gtfs-transolimpica
na issue #142release/2.2.0-stop_id-parent-stoptimes
de branch release/2.2.0-gtfs-transolimpica
feat/stop_id-parent-stoptimes
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)
O endpoint do preditor começou a retornar 0 resultados.
Possíveis causas:
service_id
estão desatualizados (2023 ao invés de 2024), portanto o preditor não teve dados atuais para gerar o resutado.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.
Semanal:
https://drive.google.com/file/d/1OWfMyi9rRtis8m2q3rsUdDeY-i-k5GiN/view?usp=sharing
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
:
Endpoints para adicionar filtro:
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/*
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:
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"
trip.json
:
{
"model": "pontos.trip",
"pk": "2200002601020101",
"fields": {
"route": "22000026010",
"headsign": "Vidigal",
"via": "",
"version": "01",
"direction": 2,
"operation_time": "Manhã"
}
README
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
Subir dados da Transolímpica em dev para teste e validação do FE
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.
Exemplo de uma API bonitona: https://rj-smtr.github.io/sigmob-api-docs/
Informar todas as linhas que passam entre 2 pontos, incluindo integrações
Ideias:
A principio da parar usar um modulo tipo networkx no python para rodar, mas podemos estudar outros.
Comportamento:
Desenvolver em pipelines
O preditor foi construido usa dados estáticos, precisamos atualizar as fontes de dados.
Desenho da arquitetura: https://miro.com/app/board/o9J_lqIY7Eg=/
feat/predictor
Será usado o gateway Konga para armazenar o endpoint em cache e só requisitar a cada 30s
Finalizar antes de lançar o app
Verificar se precisa aplicar mudanças críticas para o app funcionar corretamente.
Mudanças em branches como dev, feat e hotfix. Além de coisas necessárias para o novo GTFS.
Corrigir certificado de staging
Não é o ideal (IPField), mas torna possível receber ips, corretos ou não.
É bom testar num k8s local e ver se funciona.
Tabela FeedbackBRT:
Dado | Tipo | Propriedades | Descrição |
---|---|---|---|
like | Booleano | Obrigatório | |
comment | Caractere(120) | Opcional,não nulo, não vazio. | |
stop_code | Caractere(20) | Obrigatório | Caso selected_platform não esteja relacionado ao selected_station .O valor é seu stop_id .Não nulo, não vazio. |
stop_id | Caractere(20) | Opcional | A plataforma selecionada na estação. O valor é seu stop_id . |
route_id | Caractere(20) | Opcional | O ônibus selecionado na plataforma. O valor é seu stop_id . |
ip_address | Automático | O ip do usuário. |
API realtime será atualizada, precisamos atualizar o codigo e verificar se os trexos get_trip_id e get_true_tripid precisam ser mantidos.
Revisando o que deve acontecer:
stop_times
apenas os itens que contém aquele stop_id
stop_times
apenas os itens que contém aquele trip_id
Nesses casos já existe um filtro para isso.
O que deve ser implementado:
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.
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
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
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.
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}"
Validar os campos do GTFS BRT que estão em staging em 3 categorias de validação:
O principal motivo é garantir que os dados foram validados da melhor forma possível. Caso ocorra algum bloqueio, esta issue será de grande ajuda.
2023-02-27 11-41
e SPPO 2023-02-14 17-19
arrival_time
teve problema com tipo no banco.Resolver bloqueio sobre subida do SPPO
populate_db
para não abortar ao subirCorrigido em 06/03/2023, 20:30
arrival_time
para durationCorrigido 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
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,44Legenda - Comparando com o Google Transit:
obrigatório
obrigatório com critérios*
opcional
stops:
stop_code
stop_desc
.platform_code
.
Os critérios dos demais campos seguem o modelo do Google Transit e gtfs.org.
stops:
stop_id
: Obrigatóriostop_name
, stop_lat
, stop_lon
: Obrigatório se location_type
= 0,1,2zone_id
: Obrigatório se existir fare_tules.txt
parent_station
: Obrigatório se location_type
= 2,3,4stop_code
, stop_desc
, stop_url
, location_type
, stop_timezone
, wheelchair_boarding
, level_id
, platform_code
: Opcionaltrips:
route_id
, service_id
, trip_id
: Obrigatórioshape_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
: Opcionalshapes:
shape_id
, shape_pt_lat
, shape_pt_lon
, shape_pt_sequence
: Obrigatórioshape_dist_traveled
: Opcionalroutes:
route_id
: Obrigatórioroute_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
ouroute_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
: Opcionalstop_times:
trip_id
, stop_id
, stop_sequence
: Obrigatórioarrival_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
: OpcionalApenas para confirmar a coerência dos dados, não há pressa para fazer isso.
parent_station
).shape_id
é obrigatório se a trip possuir shape em shapes.txt
A condicional usada é se existem shapes não usados por trips.
parent_station
de outro stop.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:
trip_short_name
, direction_id
e service_id
trip_short_name
, direction_id
e service_id
- para fins de debug.show_all=true
shape_id
, e não apenas por trip_short_name
, direction_id
e service_id
.Contributors
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.
SN
em route_short_name
populate_db
dev-local
feat/populate_sb-remove_cols_containing
a partir de dev
remove_cols_containing
, sem incluir outras funcionalidadesdev
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
Neste momento as features parecem ok para lançar o app BRT.
O app deve ser lançado em 06/02/2023
Tarefa pulada pois a lógica era feature -> PR dev -> release.
cd_dev
e cd_stag
.
Tarefa pulada pois já foi feita uma reunião com @gsperim sobre isso.
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'
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:
feat/predictor-v2
arrival_time
sempre é NaN
feat/predictor-v2
=> https://api.mobilidade.rio/
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.