Atualizar dados GTFS em produção

[gmartinsoc]

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

• [x] Corrigir dados GTFS

Tarefas

• [x] Resolver bloqueio sobre subida do SPPO

  • [x] Corrigir populate_db para não abortar ao subir

    Corrigido em 06/03/2023, 20:30

  • [x] Mudar tipagem de todos arrival_time para duration

    Corrigido em 06/03/2023, 20:30

• [x] 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!

• [X] 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)

• [x] 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)

• [x] 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.

• [x] stop não pode ser pai e filho ao mesmo tempo (ter e ser parent_station).
• [x] 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

[gmartinsoc]

GTFS do BRT com problema na exportação, alguns arquivos não estão sendo exportados. SPPO mudou o padrão _ e está com duplicações. Precisamos verificar um padrão para remover as duplicações.

Precisamos validar se as trips e a forma que identificamos expresso/parador e as plataformas nas telas do brt estão de acordo com o preenchido no GTFS.

[gmartinsoc]

Dados atualizados com mockup dos campos stop_desc e stop_code, enquanto o preenchimento é GTFS finalizado.

[fernandascovino]

Relacionado a: #140

[yxuo]

Verificando as colunas GTFS

Foram usados os arquivos GTFS mais atuais obtidos do SPPO, fornecidos pela equipe.

Critérios da validação

Seguindo os critérios mencionados acima, foi feita a validação usando um algoritmo.

• As tabelas trips, shapes, routes e stoptimes não podem ter nenhum campo como null ou blank (string vazia).

Em stops:

• Nenhum campo pode estar em branco.
• parent_station, platform_code, stop_code e stop_desc podem ter certos valores sob determinadas condições.
• stop_id, stop_name, stop_lat, stop_lon e location_type não podem ser nulos.
• zone_id e stop_url podem ser nulos. wheelchair_boarding pode ser nulo, mas seria bom preencher.

Resultado

✅ Tabelas que passaram no teste

• shapes

❌ Tabelas que falharam no teste:

stops

Adicionado em 06/02/2022 Os itens abaixo não devem ocorrer:

• "stop pai" com stop_code - 2/484
• "stop pai" sem platform_code - 154/484
• "stop filho" sem stop_code - 330/484
• "stop filho" sem stop_desc - 324/484

trips

• block_id - all null
• wheelchair_accessible - all null
• bikes_allowed - all null

routes

• route_desc - 30/34 null
• route_type - ok ✅
• route_url - all null
• route_branding_url - all null
• route_sort_order - all null
• continuous_pickup - all null
• continuous_drop_off - all null

stoptimes

• stop_headsign - all null
• pickup_type - 1884/2691 null
• drop_off_type - 1884/2691 null
• continuous_pickup - 1897/2691 null
• continuous_drop_off - 1897/2691 null
• timepoint - 807/2691 null

Com este resultado, o que pode ser feito?

Todas as tabelas, exceto stops, possuem pelo menos uma coluna com todas as ocorrências inválidas, tornando impossível subi-las.

Com isso temos as seguintes opções:

• Corrigir os dados do GTFS e só subir no banco do Django se todos forem validados;

• Permitir ou revisar quais colunas realmente não podem ser nulas ou vazias.

---

Caso deseje testar, será deixado o arquivo jupyter e log em anexo:

Atualizado em 06/02/2022 validate-gtfs 2022-02-06.zip

[yxuo]

A tabela stops passou pela validação hoje (06/02/2022) e falhou. O comentário acima foi atualizado.

[yxuo]

Reunião sobre as falhas na 1ª validação

Foi feita reunião hoje (08/02/2023 10:50) com @gsperim e @gbragaalves sobre o GTFS e entendeu-se que:

O que foi definido sobre os requisitos

Em todas as tabelas

• As colunas GTFS do BRT seguem o modelo da Google Transit. Portanto colunas opcionais ou não serão baseadas nele.

Em stops:

• Todos e somente os stop pai devem ter stop_code.
• Todos e somente os stop filho devem ter platform_code.
• Todos e somente os stop filho devem ter stop_desc.

Se alguma informação acima estiver equivocada, podem avisar!

Portanto, o que será feito

• Os requisitos citados no primeiro comentário serão atualizados junto com as tarefas.
• Será feita uma nova validação com os novos critérios, o restultado será informado em um comentário posterior.

[yxuo]

A issue foi fechada por engano.

[yxuo]

Validação dos dados GTFS - tentativa 2

Foram usados os mesmos arquivos GTFS mais atuais obtidos do SPPO, fornecidos pela equipe (veja o comentário da 1ª tentativa de validação).

Resumo

Validação do GTFS - passou ✅

Validação da SMTR (stop pai e filho) - falhou ❌

• stops pai sem stop_code: 152/484
• stops filho sem platform_code: 330/484
• stops filho sem stop_desc: 324/484

Validação de campos usados pelo frontend - falhou ❌

• stop_code 482/484 null

Critérios da validação

Seguindo os critérios mencionados no primeiro comentário da issue, foi feita a validação usando um algoritmo.

Essas informações são repetidas aqui pois o primeiro comentário mostra apenas os últimos critérios adotados.

Validação do GTFS

• Nenhum campo pode estar em branco.

Validação do Frontend

• Nenhum campo pode estar em branco.
• Todos os campos a seguir são obrigatórios.

stops:

• stop_code, stop_lat, stop_lon e stop_name são obrigatórios

stop_times:

• stop_id e trip_id são obrigatórios

trips:

• trip_id é obrigatório.

shapes:

• shape_id, shape_pt_lat e shape_pt_lon são obrigatórios

Validação da SMTR

• Nenhum campo pode estar em branco.
• Todos e somente os stops pai devem ter stop_code
• Todos e somente os stops filho devem ter stop_desc.
• Todos e somente os stops filho devem ter platform_code = 1,2,3,4.

Onde:

• "stop pai" é todo stop que não possua parent_station
• "stop filho"é todo stop que possua parent_station

Resultado

Validação do GTFS - passou ✅

Todas as tabelas analisadas passaram nessa validação:

• stops, trips, shapes, routes (incluindo route_type) e stop_times.

Validação do frontend

Tabelas analisadas:

• stops, trips, shapes e stop_times.

✅ Tabelas que passaram nessa validação:

• trips
• shapes
• stoptimes

❌ Tabelas que falharam:

stops

• stop_code - 482/484 null.

  Usado em Home:65 e outros

Validação da SMTR

✅ Critérios que passaram:

• Somente os stops filho devem ter platform_code

  • parent_with_platform_code - nenhum

• Todos os stops filho não nulos devem ter platform_code = 1,2,3,4

  • child_invalid_platform_code - nenhum

• Somente os stops filho devem ter stop_desc

  • parent_with_stop_desc - nenhum

• Somente os stops pai devem ter stop_code

  • child_with_stop_code - nenhum

❌ Critérios que falharam:

• Todos stops pai devem ter stop_code

  • parent_no_stop_code - 152/484

• Todos stops filho devem ter platform_code

  • child_no_platform_code - 330/484

• Todos stops filho devem ter stop_desc

  • child_no_stop_desc - 324/484

📋 Critérios hipotéticos (para usar na reunião):

• ❌ Todos stops filho devem ter stop_code

  • alt_child_no_stop_code - 330/484

• ❌ Somente os stops filho devem ter stop_code

  • alt_parent_with_stop_code - 2/484

• ❌ Todos stops pai devem ter stop_desc

  • alt_parent_no_stop_desc - 154/484

• ❌ Somente os stops pai devem ter stop_desc

  • alt_child_with_stop_desc - 6/484

• ❌ Todos stops pai devem ter platform_code não nulo

  • alt_parent_no_platform_code - 154/484

• ✅ Todos stops pai não nulos devem ter platform_code = 1,2,3,4

  • alt_parent_invalid_platform_code - nenhum

• ✅ Somente os stops pai devem ter platform_code

  • smtr__alt_child_with_platform_code - nenhum

Com este resultado, o que pode ser feito?

• [x] Verificar com @Gabriel0109 se o app funciona normalmente sem o stop_code e quais as consequências de não ter este campo para o usuário.

  Se a ausência deste campo impedir o usuário de usar o QRCode, será necessário corrigir.

• [x] Confirmar com @gbragaalves os critérios de stop pai e filho. Dependendo da resposta pode haver campos invalidados.

  Havendo campos inválidos, será necessário corrigir ou contornar esses erros.

---

Caso deseje testar, será deixado o arquivo jupyter em anexo: 2023-02-09 validate gtfs v2.zip

[yxuo]

Reunião com o Frontend sobre a validação (tentativa 2)

Foi feita reunião hoje (13/02/2023 13:20) com @Gabriel0109 sobre o GTFS.

Problema

stop_code falhou na validação.

O que foi definido sobre sobre o stop_code

• Stops sem stop_code significam que eles não foram cadastrados ainda. Portanto este campo seria opcional, e não obrigatório.
  • Mas é preciso confirmar esta informação com a equipe ou responsável por este GTFS.
• O app foi projetado para não pesquisar stops sem stop_code.

  Ou seja, esse comportamento faz parte da lógica do frontend v2.1.0

O que será feito?

Caso seja necessário, o app seria capaz de pesquisar stops sem stop_code.

Portanto, o melhor é conversar com o responsável pelo GTFS sobre o que deve ser feito com os dados.

[yxuo]

Reunião com o responsável pelo GTFS BRT sobre a validação (tentativa 2)

Foi feita reunião em 14/02/2023 11:20 com @gbragaalves e @gsperim sobre o GTFS.

Resumo

Sobre o frontend:

• Stops sem stop_code significam que eles não foram cadastrados ainda. Portanto este campo será opcional, e não obrigatório.

  Isto não será problema para o Frontend (v2.1.0) pois ele ignora stops sem QR Code.

Sobre a validação SMTR (stop pai e filho):

• @gbragaalves vai analisar os stops com erro. Os campos que não puderem ser preenchidos serão opcionais e, portanto, validados. Porém, para fins de informação os erros desses campos serão informados.

  Não há previsão mas espera-se um retorno em até o fim da próxima semana (24/02/2023).

Sobre como obter informação do corredor

• Em stop_code terá o prefixo TC para trancarioca e TO para transolímpica e assim por diante.
• Idealmente toda estação do BRT fica dentro de um corredor, mas caso contrário o prefixo de corredor dos stops é opcional.

  Em futuras validações é sempre bom verificar com os responsáveis se há alguma atualização de dados como esse.

Sobre os erros na validação de stop pai e filho

Por garantia, a segunda tentativa de validação previu erros caso um campo seja do stop pai ou do stop filho. Foi feita a confirmação dos critérios de validação para então mostrar o resultado.

O que foi definido

Os critérios usados estavam corretos:

• 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 = 1,2,3,4.

Portanto houve os seguintes erros:

• parent_no_stop_code - 152/484
• child_no_platform_code - 330/484
• child_no_stop_desc - 324/484

O que será feito

• Foi enviado para @gbragaalves um arquivo com os stops com erro.

  O arquivo será avaliado e os campos stop_code, platform_code e stop_desc serão preenchidos até onde for possível.

• Caso não seja possível preencher alguns desses campos eles devem seguir a validação GTFS, portanto serão opcionais e validados automaticamente.

Sobre o stop_code que falhou na validação do frontend

O que foi definido

• Stops sem stop_code são estações que não possuem selos de QR Code cadastrados nas estações, ou são estações com o selo mas que não foram mapeadas pela SMTR.

• @gbragaalves não possui em mãos quais stops tem QRCode.

• Stops sem stop_code são opcionais caso não estejam cadastrados oficialmente nas estações.

O que será feito

• @gbragaalves vai analisar os stops com erro. Os campos que não puderem ser preenchidos serão opcionais e, portanto, validados.

• É preciso saber quem é responsável por mapear fisicamente os stops com QRCode.

  Isso facilita a comunicação e futuramente seria bom utilizar um meio automático de atualizar esses dados.

Sobre como obter informação do corredor

• Em stop_code terá o prefixo TC para trancarioca e TO para transolímpica e assim por diante.
• Idealmente toda estação do BRT fica dentro de um corredor, mas caso contrário o prefixo de corredor dos stops é opcional.

  Em futuras validações é sempre bom verificar com os responsáveis se há alguma atualização de dados como esse.

[yxuo]

Validação dos dados GTFS - tentativa 3

Foram usados os arquivos GTFS BRT de 24/02/2023, que são os mais atuais obtidos do SPPO, obtidos direto da fonte usada pela equipe.

Resultado do GTFS BRT

✅ Validação do GTFS - passou

✅ Validação de campos usados pelo frontend - passou

❌ Validação da SMTR (stop pai e filho) - menos erros que antes (validação, tentativa 2)

• stops pai sem stop_code: 152 -> /21
• stops filho sem platform_code: 330 -> /164
• stops filho sem stop_desc: 324 -> /165

Com este resultado, o que pode ser feito?

• Subir os dados assim mesmo, pois esses campos são opcionais no GTFS.

Script jupyter em anexo: 2023-02-24 validate gtfs v3.zip

---

Critérios da validação

Os critérios foram definidos na reunião sobre a validação, tentativa 2.

Criterios do GTFS

Os campos seguem o modelo do Google Transit e gtfs.org.

Os critérios abaixo são os mesmos, apenas com outras palavras para aplicar no script.

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

  A princípio será opcional. Esta verificação é mais sofisticada, pode ser feita numa próxima validação.

• 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ção do Frontend

• Nenhum campo pode estar em branco.

stops:

• stop_lat, stop_lon e stop_name são obrigatórios
• stop_code agora é opcional.

stop_times:

• stop_id e trip_id são obrigatórios

trips:

• trip_id é obrigatório.

shapes:

• shape_id, shape_pt_lat e shape_pt_lon são obrigatórios

Validação dos stops pai e filho

• Nenhum campo pode estar em branco.
• Todos e somente os stops pai devem ter stop_code
• Todos e somente os stops filho devem ter stop_desc.
• Todos e somente os stops filho devem ter platform_code = 1,2,3,4.

Onde:

• "stop pai" é todo stop que não possua parent_station
• "stop filho"é todo stop que possua parent_station

[yxuo]

Validação dos dados GTFS - tentativa 4

Hoje, 02/03/2023, foram usados os arquivos GTFS BRT atualizados em 27/02/2023, obtidos do SIGMOB e carregados no banco de dados da api.

Resultado do GTFS BRT

✅ Validação do GTFS - passou

✅ Validação de campos usados pelo frontend - passou

❌ Validação da SMTR (stop pai e filho) - menos erros que antes (validação, tentativa 3)

• stops pai sem stop_code: 21 -> 20
• stops filho sem platform_code: 164 -> 27
• stops filho sem stop_desc: 165 -> 29

Com este resultado, o que pode ser feito?

• Informar os erros.
• Subir os dados assim mesmo, pois esses campos são opcionais no GTFS.

Script jupyter em anexo: 2023-03-02 validate gtfs v4.zip

---

Critérios da validação

Os critérios usados encontram-se na validação, tentativa 3.

[yxuo]

Hoje, 03/03/2023, foram enviados os stops que falharam no critério de stop pai e filho validação, tentativa 4

[yxuo]

Os dados do GTFS de BRT + SPPO do dia 10/03/2023 foram carregados em dev e staging.