Documentação do processo de aplicação de multas - RJ-SMTR/maestro GitHub Wiki

Capturas:

Os dados geoespaciais, tanto do SPPO quanto do BRT, são capturados a cada 1 minuto usando as pipelines br_rj_riodejaneiro_onibus_gps e br_rj_riodejaneiro_brt_gps, cujo código está disponível dentro de repositories/capturas/ nos arquivos registros.py.

Descrição das pipelines:

  • Os dados são capturados das respectivas API's usando requests. Para cada requisição, definimos um timeout de 60s. Chamamos este passo de get_raw. Além de fazer uma requisição para a API, o get_raw gera uma timestamp no momento da requisição que será utilizada nos passos posteriores.

  • Após salvar localmente os dados requisitados (save_raw_local), um pré tratamento é realizado nos dados. Nesse passo, adicionamos um campo novo à tabela de registros chamado timestamp_captura, cujo valor é a timestamp gerada ao baixar os dados em get_raw.

  • Os dados são salvos localmente na máquina virtual, é feito o upload para o BigQuery, no projeto rj-smtr, numa tabela chamada registros, dentro do respectivo dataset (br_rj_riodejaneiro_< onibus/brt >_gps).

Tratamento dos dados após a captura:

  • Após criar a tabela de registros, o tratamento posterior é feito usando Standard SQL disponível ao BigQuery. O primeiro passo desse tratamento é retirar os registros de veículos que estejam parados nas garagens e de pontos outliers que estejam fora dos limites do município do Rio de Janeiro. O resultado desse tratamento é salvo na tabela registros_tratada

    • Remoção de outliers: consideramos outliers os pontos de gps que estão fora dos limites do município do Rio de Janeiro. A geometria utilizada para essa remoção pode ser encontrada na tabela rj-smtr.br_rj_riodejaneiro_geo.limites_geograficos_caixa
    • Remoção de veículos em garagens: para este passo, geramos os polígonos das garagens usando os dados do campo WKT da tabela rj-smtr.br_rj_riodejaneiro_geo.garagens_polygon e fazendo sua intersecção com os pontos de gps da tabela de registros. Este passo é aplicado somente aos dados do SPPO.

  • Usando a registros_tratada como base, fazemos uma agregação contando o número de veículos (identificados por ordem para SPPO ou codigo para o BRT, na tabela de registros) que estão operantes e cujos dados estamos captando, por linha, data e hora. Essa é a tabela registros_agg_data_hora_linha.

  • A partir dessa agregação, calculamos a frota operante média para um dado período de tempo, usando uma média simples da contagem de veículos por período especificado, por exemplo, nos chamados picos da manhã (5:00 às 8:00) e pico da noite (16:00 às 19:00), e cruzamos essas informações com as fornecidas pelo SIGMOB sobre a frota planejada para cada período. Temos campos que representam uma frota medida abaixo de 100% e abaixo de 80% do planejado.

Casos excepcionais de falta de registros

A falta de registros de gps podem acontecer por algumas razões:

  1. O sistema de captura da SMTR está fora do ar
  2. A API do [onibus/BRT] está fora do ar
  3. A API do [onibus/BRT] retorna um resultado nulo

Regra 1. O cálculo de multa para a hora só será efetuado se a captura da SMTR tiver adquirido pelo menos 45 registros. Isto é, o problema tipo 1 aconteceu em menos de 15 vezes na hora.

Regra 2. Se API apresentar problemas do tipo 2 ou 3 em mais de 10% dos registros capturados pela SMTR, a API será considerada instável e passível de multa.

Exemplos:

  1. A SMTR capturou 60 registros na hora e a API apresentou problemas do tipo 2 ou 3 em 5 registros. Então, a API apresentou problemas 5/60 = 8.3%, logo não será passível de multa
  2. A SMTR capturou 60 registros na hora e a API apresentou problemas do tipo 2 ou 3 em 10 registros. Então, a API apresentou problemas 10/60 = 16.6%, logo será passível de multa
  3. A SMTR capturou 45 registros e a API apresentou problemas do tipo 2 ou 3 em 5 registros. Então, a API apresentou problemas 5/45 = 11.1%, logo será passível de multa
  4. A SMTR capturou 30 registros, então a hora não entrará no calculo da média.

Monitoramento de uptime das API's:

  • A timestamp gerada ao baixar os dados, também é utilizada para subir uma tabela chamada registros_logs dentro do mesmo dataset que a tabela de registros original. Essa tabela monitora, para cada requisição feita, se a mesma foi bem sucedida ou se ocorreu algum erro. Na tabela, o campo sucesso assume valores booleanos e erro é nulo para caso de sucesso na requisição.