Adiciona código para mapeamento de sistemas replicáveis

[trevineju]

Descrição Começa a desenvolver os scripts para mapeamento de sistemas replicáveis ( https://github.com/okfn-brasil/querido-diario/issues/919 ), adicionando uma classe base para mapeamento e os mapeadores para DOSP e SIGANET.

PR ainda sendo trabalhado

[trevineju]

Tenho alguns ajustes pra propor, mas o que queria endereçar primeiro é onde o código vai ficar. Duas possibilidades:

1. Ficar em /scripts, e aí iniciar um projeto scrapy lá
2. Ficar em /data_collection como está no PR, porém organizado de outra forma. a. Hierarquia de diretórios: Ao invés de abrir um novo diretório só para o mapeamento, poderia acomodar dentro da estrutura como está hoje: a classe base mapeador.py junto às demais classes bases do QD mesmo (onde tem doem, instar, etc), e aí as classes mapeadoras poderia ficar em um diretório mapeadores em spiders mesmo. b. Output: Não tenho certeza do melhor lugar para deixar o .csv gerado, mas acho que poderia ser apenas um arquivo, que será atualizado a cada rodada de mapeamento, ao invés de gerar um arquivo por interação.

Essa sugestão vai na esteira de outra ideia, de seguir agrupando os raspadores em diretórios por Estado (já tem PE, poderia ter os demais Estados tb). Visualizo o repositório ficando assim no futuro, a partir do diretório spiders:

--- base
    |--- adminlte.py
    |--- aplus.py
    |--- doem.py
    |--- ... outras bases
    |--- mapeador.py                               (novo)
--- pe
    |--- recife_2015.py
    |--- recife_2020.py
    |--- ... outros raspadores de PE               (novo)
--- ba                                             (novo)
    |--- ... raspadores da BA                      (novo)
... vários diretórios por UF e seus raspadores     (novo)
--- mapeadores                                     (novo)
    |--- mapeadorDoem.py                           (novo)
    |--- mapeadorDosp.py                           (novo)

O que vocês acham? @Winzen @ogecece @rennerocha

Particularmente, gosto dessa segunda ideia. Sei que misturar os raspadores de mapeamento entre os raspadores de cidades poderia gerar confusão, mas se juntar com uma organização geral do diretório (com os diretórios filhos por Estado), balanceia a solução; sem precisar iniciar outro scrapy project em scripts

[trevineju]

Fiz algumas atualizações no código. Dá uma reorganizada nas coisas, mas no geral, o principal que mudei tem a ver com como ficaram as classes filhas de Mapeador.

Originalmente (em commit hash), estava:

class MapeadorDosp(Mapeador):
    name = "dosp"
    format_url = "https://www.imprensaoficialmunicipal.com.br/@city"
    sep = "_"
    preference_state_code = "SP"

• format_url: não é bom ser um atributo da classe, pq tem sistemas que tem mais de um formato de URL. Acho melhor ser um método que repassa para a classe mãe as urls a serem testadas.
• sep e preference_state_code: me pareceu que é uma opção meio on/off de permitir usar ou não essas preferências, e daria pra optar por não usar, mas acho que não é necessário pq a intenção é justamente criar todas as urls possíveis e testar todas elas, com diferentes separadores e em todos os estados, sempre. Brute force mesmo.

Novo desenho das classes filhas:

class Mapeador<NOME>(Mapeador):
    name = ""
    def new_column(self)
    def urls_pattern(self, city, state_code)
    def validation(self, response)

• new_column(): dialoga com a proposta que tinha feito acima, de não gerar um arquivo novo a cada rodada de mapeamento, mas sim atualizar um arquivo único. Esse método define o nome da nova coluna do CSV.
  Consequentemente, na classe base mapeador.py tem um método (add_column_key()) que adiciona a coluna nova (no caso, estamos usando um dict, então na prática adiciona uma nova chave)
• urls_pattern(): gera as urls padrão daquele sistema. Devolve uma lista de URLs.
• validation(): só porque uma URL por ventura é válida (response 200), não significa que é do sistema sendo testado. Esse método verifica se na response obtida há algo que confirme que é uma URL desejada.

[trevineju]

Nessa correção, já adicionei mais um monte de outros mapeadores como vocês podem ver.

Já até rodei ontem uma coleta parcial: https://docs.google.com/spreadsheets/d/18cIxZxdugPBkBs4R-14oy2xqGr7CHJi4zuCqG8dKM0Y/edit#gid=2115781612

Acredito que os mapeadores DOEM, DOSP, INSTAR, SIGANET, ADIARIO e AJAXPRO estejam bons (mas não cliquei um a um, experimento apenas uma amostra).

Já outros, APLUS, ADMINLTE e IMPRENSAOFICIAL não estão muito bons. Precisa investigar se faltam formatos de url ou se é o validador que não está pegando os casos direito.

Em especial, o da Imprensa Oficial parava no meio da execução, apontando que o scrapy estava com muitos arquivos abertos. Reduzi as CONCURRENT_REQUESTS de 100 para 25 e resolveu.

Mas a boa notícia é que só estes mapeadores, ainda que nem todos excelentes por enquanto, já acharam mais de 700 urls pro QD ❤️ Parte destes 700 já conheciamos (vários DOEM e DOSP), mas muito bom termos mais informações do panorama.

[trevineju]

Após alguns ajustes, na nova versão estamos mapeando 2072 municípios de diário agregado (SIGPUB) e outros 1462 municípios em sistemas replicáveis, num total de 3174 cidades (uma mesma cidade pode aparecer em mais de um sistema).

Para conferir a validação, abri diversas URLs, porém não todas. Validei por amostra. Por isso, pode haver casos que passam. Estes sistemas replicáveis novos parecem publicar, em grande parte, como PDF texto, porém há casos de PDF Imagem e diários fragmentados. É necessário conferir os nomes dos mapeadores, pois alguns foram dados de forma artificial.

Completo

Executado todos os mapeadores deste PR, um arquivo único de mapeamento é gerado, com URLs válidas e URL inválidas, mas existentes.

• Recorte do arquivo apenas com as URLs desejadas: [versao 2] dados_mapeamento.csv. Para facilitar navegação, também foi disponibilizado no Drive
• Versão completa: [versao 2] dados_mapeamento_com_invalidas.csv

Explorar o arquivo com as URLs inválidas é muito interessante, possibilita encontrar outros padrões.

Considerações

Para comparar os mapeadores, uma aba "Panorama" foi criada no link do Drive. Lá, são registradas algumas coisas:

• coleta os casos de partida: Se, entre os casos do mapeamento, os casos de exemplo (estão documentadas no mapeador), que foram o ponto de partida, são coletados.

  No geral, sim, todos os casos de partida estão sendo encontrados.

• validador de presença de diários: a validação precisa verificar duas coisas - se é o sistema replicável de interesse e se há diários publicados ali (não está vazio).

  Há validação dupla: 14 casos; Tem a validação do sistema, mas não tem o de presença de diários: 18 casos. Tem a validação de presença de diários, mas não tem o do sistema: 1 caso. Não precisa de validação: 1 caso.

• formatos: quantos formatos diferentes de padrão de URL são tentadas no mapeamento.

  Notar que a URL tentada e a URL da response podem ser diferentes

• domínio não-governamental: se o domínio que publica os diários são diferentes de .{uf}.gov.br.

  Este registro foi considerado relevante pois há casos de referências erradas no mapeamento por conta de homônimos. Por exemplo: A URL https://miracema.diariooficialbr.com.br/ se refere à Miracema do Tocantins (TO), porém está registrada como Miracema (RJ) no mapeamento. Em casos de domínios governamentais, não parece ter problemas já que a relação UF -> município é concretizada. Portanto, este é um possível viés do mapeamento: ele encontra URLs de interesse, mas vincula na cidade errada.

• casos pendentes: novos casos encontrados depois da execução do mapeamento e que, portanto, ainda não estão cobertos.
• obs: alguma observação específica.

Destaques

• O sistema SAI e o IMAP são diferentes.
• Todas as URLs inválidas do IPM são úteis, uma vez que tem a versão inativa do site (ver no arquivo do IPM)
• Os layouts de DKC, EPortal e Vale são próximos. DKC e EPortal em particular são os mesmos, porém Vale, não.
• ADiario e SIASP são bem próximos, mas não são iguais.
• Portal Fácil, Siganet e ADiário parece ter um delay para carregar informações da página, isso afeta o validador.
• Tem alguns casos que achei dois exemplos de layout, mas não mais do que isso. Não ficou claro que só tem esses dois casos mesmo, ou se é limitações da lógica de mapeamento. No documento tem: AdminLTE, JDOWN, MEGAS e SISTA. Outros são: (a) https://diariooficial.palmeirasdotocantins.to.gov.br/ | https://diariooficial.darcinopolis.to.gov.br/ (b) https://diariooficial.natividade.to.gov.br/ | https://diariooficial.portonacional.to.gov.br/
• AdminLTE e Geddoem tem um desempenho bem ruim. AdminLTE demora muito para executar e quebra. Geddoem gera muitas URLs de portais de transparência, tornando a conferência muito poluída.

Arquivos individualizados

ADiario - arquivo: [ADIARIO] dados_mapeamento_parcial.csv AdminLTE - arquivo: não há. Agape - arquivo: [AGAPE] dados_mapeamento_parcial.csv Aplus - arquivo: [APLUS] dados_mapeamento_parcial.csv Barco - arquivo: [BARCO] dados_mapeamento_parcial.csv CONTECN - arquivo: [CONTECN] dados_mapeamento_parcial.csv CR2 - arquivo: [CR2] dados_mapeamento_parcial.csv

O sistema parece possibilitar diários únicos (exemplo) ou fragmentados (exemplo). O mapeador está coletando apenas os únicos.

DALINS - arquivo: [DALINS] dados_mapeamento_parcial.csv DIOENET - arquivo: [DIOENET] dados_mapeamento_parcial.csv DKC - arquivo: [DKC] dados_mapeamento_parcial.csv DOBR - arquivo: [DOBR] dados_mapeamento_parcial.csv DOEM - arquivo: [DOEM] dados_mapeamento_parcial.csv DOME - arquivo: [DOME] dados_mapeamento_parcial.csv DOSP - arquivo: [DOSP] dados_mapeamento_parcial.csv E-Atos - arquivo: [EATOS] dados_mapeamento_parcial.csv E-portal - arquivo: [EPORTAL] dados_mapeamento_parcial.csv Imprensa Oficial - arquivo: [IMPRENSA OFICIAL] dados_mapeamento_parcial.csv Instar - arquivo: [INSTAR] dados_mapeamento_parcial.csv IPM - arquivo: [IPM] dados_mapeamento_parcial.csv IWEB - arquivo: [IWEB] dados_mapeamento_parcial.csv JDOWN - arquivo: [JDOWN] dados_mapeamento_parcial.csv MAX - arquivo: [MAX] dados_mapeamento_parcial.csv MEGAS - arquivo: [MEGAS] dados_mapeamento_parcial.csv Nucleo GOV - arquivo: [NUCGOV] dados_mapeamento_parcial.csv PHOCA - arquivo: [PHOCA] dados_mapeamento_parcial.csv Portal Fácil - arquivo: [PORTALFACIL] dados_mapeamento_parcial.csv SAI IO - arquivo: [SAIIO] dados_mapeamento_parcial.csv SIASP - arquivo: [SIASP] dados_mapeamento_parcial.csv Siganet - arquivo: [SIGANET] dados_mapeamento_parcial.csv SigPub - arquivo: [SIGPUB] dados_mapeamento_parcial.csv Tres Tecnos - arquivo: [TREST] dados_mapeamento_parcial.csv Vale - arquivo: [VALE] dados_mapeamento_parcial.csv Sistema sem Nome A - arquivo: [SISTA] dados_mapeamento_parcial.csv Sistema sem Nome B - arquivo: [SISTB] dados_mapeamento_parcial.csv Sistema sem Nome C - arquivo: [SISTC] dados_mapeamento_parcial.csv

Casos ainda não mapeados, para serem atacados no futuro:

Sistemas replicáveis:

• FECAM
• DexaTec
• IMAP (https://dom.imap.org.br/sitesMunicipios/imprensaOficial.cfm?varCodigo=411)
• https://getpublic.inf.br/
• IMPublicações (parece ser fragmentado): https://impublicacoes.org/agenda/index.php?type=pref&municipio=TWprd09Ua3dNUT09#

Associações:

• http://diariooficialms.com.br/assomasul

[trevineju]

Deixei um comentário geral acima, tentando compartilhar conhecimento sobre a atividade, mas endereçando o que @ogecece trouxe em específico, sugiro o mapeador do adiario para integração.

[rennerocha]

Esse PR está ficando bem grande pra ser revisado de uma vez só. Sugiro que quando for fechar o rascunho pra colocar pra revisão que seja escolhido apenas um mapeador representativo pra gente validar como será feita a integração no repo primeiro e depois a gente ir adicionando os outros mapeadores.

Concordo com o @ogecece . Vai ser impossível revisar esse PR inteiro. Se queremos fazer scripts utilitários para essa busca, acredito que criar um de referência para definir a estrutura e depois fazer um PR para cada um.