[WIP - Preciso de feedback] Add spider de sc_itapema

[gpr-indevelopment]

AO ABRIR uma Pull Request de um novo raspador (spider), marque com um X cada um dos items da checklist abaixo. Caso algum item não seja marcado, JUSTIFIQUE o motivo.

Layout do site publicador de diários oficiais

Marque apenas um dos itens a seguir:

• O layout não se parece com nenhum caso da lista de layouts padrão
• É um layout padrão e esta PR adiciona a spider base do padrão ao projeto junto com alguns municípios que fazem parte do padrão.
• É um layout padrão e todos os municípios adicionados usam a classe de spider base adequada para o padrão.

Código da(s) spider(s)

• O(s) raspador(es) adicionado(s) tem os atributos de classe exigidos.
• O(s) raspador(es) adicionado(s) cria(m) objetos do tipo Gazette coletando todos os metadados necessários.
• O atributo de classe start_date foi preenchido com a data da edição de diário oficial mais antiga disponível no site.
• Explicitar o atributo de classe end_date não se fez necessário.
• Não utilizo custom_settings em meu raspador.

Testes

• Uma coleta-teste da última edição foi feita. O arquivo de .log deste teste está anexado na PR.
• Uma coleta-teste por intervalo arbitrário foi feita. Os arquivos de .loge .csv deste teste estão anexados na PR.
• Uma coleta-teste completa foi feita. Os arquivos de .log e .csv deste teste estão anexados na PR.

Verificações

• Eu experimentei abrir alguns arquivos de diários oficiais coletados pelo meu raspador e verifiquei eles conforme a documentação não encontrando problemas.
• Eu verifiquei os arquivos .csv gerados pela minha coleta conforme a documentação não encontrando problemas.
• Eu verifiquei os arquivos de .log gerados pela minha coleta conforme a documentação não encontrando problemas.

Descrição

Muitos municípios de Santa Catarina utilizam a plataforma CIGA e o sistema "Diário Oficial" para publicar seus diários. Essa plataforma emite uma edição diária em formato PDF que contém todos os munícipios que aderiram a plataforma. Trecho em anexo. Não é possível anexar o PDF inteiro por limitações de tamanho do GitHub.

sc_itapema_5008_extracted.pdf

A abordagem que estou seguindo é: Baixar o PDF da edição geral, e usar um parser de PDF para extrair as páginas referentes ao município de Itapema em SC. Em um segundo momento podemos evoluir essa solução e seguir a mesma ideia para extrair dados de todos os municípios que já vem no PDF (+100)

O sistema do QD espera que cada spider retorne (yield) um arquivo a ser baixado, mas nesse cenário precisamos de uma etapa de pós processamento do arquivo baixado para chegar no que interessa, o que não parece ainda ser suportado.

Para tal, estou baixando o PDF dentro do spider e mandando um arquivo base64 encoded para a pipeline que agora sabe diferenciar entre "arquivos a baixar" e "arquivos já baixados".

Tentei também criar uma etapa de pipeline nova para pós processamento mas considerei essa uma solução menos clean (podemos entrar em detalhes se necessário).

Esse PR é WIP (work in progress). Ainda tenho vários pontos para trabalhar aqui como podem verificar pelos TODO's que deixei. Preciso de um feedback do time do QD com relação a solução adotada para o scrape dessa plataforma já que não segue padrões de outras no sistema.

[firefueled]

Investiguei o site e realmente parece que este sistema CIGA não dá uma forma de pegar os DOs de cada cidade individualmente.

Eu acho que esta estratégia que você propõe é a correta caso não tenhamos outras opções, entretanto, como ela demanda mudanças significativas na forma que o sistema por inteiro funciona, eu diria que, antes, deveríamos esgotar as opções de obter os DOs individualmente, da forma que as outras cidades do país fazem.

Assim, eu mandei um email para o suporte ciga@ciga.sc.gov.br perguntando como ter acesso aos PDFs individuais. Vamos ver o que respondem.

Se esta estratégia for viável e considerando que grande parte da raspagem de um município seria igual à todos os outros, eu diria que a repartição do pdf deveria acontecer numa camada acima dos raspadores, alguma classe mãe que representaria um tipo diferente de digestão de DOMs, com os raspadores municipais provendo apenas configuração.

Acabei encontrando outro estado que centraliza DOMs.

Obrigado pela contribuição. Muito do que fez dá pra ser usado nesta forma diferente de digestão. Vamos ver o que ou outros dizem.

[gpr-indevelopment]

Concordo com a visão de expansão para os demais municípios e sua sugestão de abstração. Minha ideia era submeter primeiro Itapema, e depois trabalhar em um follow-up que expande o conceito para os demais municípios. Minha maior dificuldade no design dessa solução está sendo adaptar as etapas de pipelines que estão acopladas a expectativa de cada spider em retornar um arquivo a ser baixado.

Vocês enxergam algum problema/risco na melhoria que fiz na classe QueridoDiarioFilesPipeline? Fiquei me perguntando se não seria melhor essa 'classe mãe' e os demais raspadores terem um pipeline próprio e mais específico mas vi na documentação de vocês que o uso de custom_settings é desencorajado.

[gpr-indevelopment]

deveríamos esgotar as opções de obter os DOs individualmente

Sobre isso, uma outra opção é fazer a busca dessa forma, retornando componentes individuais que estaríam no DO para um dia específico. Eu experimentei com essa abordagem e os drawbacks são 2:

1. O resultado da raspagem de um dia seria um conjunto de arquivos (mix entre PDF e DOCX), e não um DO único como os demais municípios. Seria necessário um merge?
2. Encontrei muitos casos com arquivos de pouca formatação, que nem parecem oficiais. Fiquei na dúvida se teriam qualquer validade. O PDF da edição geral me pareceu a forma mais 'oficial' de coletar as informações.

De todo modo, aguardando a resposta do email.

[firefueled]

Vocês enxergam algum problema/risco na melhoria que fiz na classe QueridoDiarioFilesPipeline?

Eu não conheço a parte interna de processamento de arquivos, então minha opinião vale pouco aqui.

Sobre isso, uma outra opção é fazer a busca dessa forma, retornando componentes individuais que estaríam no DO

Eu notei que eles oferecem arquivos para cada parte da publicação que entraria num DOM e pensei em agregá-los também. Entretanto, a agregação não funcionaria para nós, caso seja necessário termos uma versão 'oficial' guardada.

Por outro lado 🤔, se pensarmos que o objetivo principal do Querido Diário não é ter cópias de DOMs, mas sim prover pesquisa sobre eles, então não precisaríamos nos preocupar em criar estas versões individuais, e nem repartir a versão geral.

[firefueled]

A leitura da versão geral seria suficiente para disponibilizar os seus dados na nossa pesquisa, e, teoricamente, seria possível associar os resultados da busca a municípios individuais presentes no pdf geral.

A diferença para o usuário seria ao tentar baixar o PDF, recebendo um arquivo maior do que o esperado. Não vejo isso como problema se for propriamente identificado que aquele município usa este tipo diferente de publicação agregada.

[gpr-indevelopment]

Confirma meu entendimento? Você está sugerindo que o raspador de Itapema (e de qualquer outra cidade de SC) faça o download da edição geral do diário completa sem extrair a parte correspondente a cada município.

Isso não traria um problema de ineficiência e escalabilidade ao expandir para as demais cidades de SC? Já que cada uma faria o download da mesma edição completa. Mais de 100 cidades com um PDF de 50 MB cada totalizando 5 GB diários.

A não ser que exista algum mecanismo de reaproveitamento/cache no QD onde não seja necessário que cada município baixe mais uma edição geral

[firefueled]

Me entendeu errado. Não sugiro que armazenemos o mesmo PDF gigante para cada município. Como disse, seria bem ineficiente.

Ao identificar que um grupo de cidades faz parte de uma publicação geral (agregada), armazenaríamos apenas um PDF geral, que seria indexado de forma a identificar que ele tem dados de múltiplos municípios.

Depois, nos resultados de pesquisas, teríamos uma identificação de que aquele resultado está no meio de um PDF com múltiplas cidades. Isso evitaria confusão do usuário ao receber um PDF gigante, com muito mais coisas do que esperado.

Isso evitaria termos que baixar, ler e recortar o mesmo PDF múltiplas vezes em cada raspador.
Deixaríamos o trabalho de parsear o PDF geral para o usuário, assim como este teria que fazer ao usar o site original.

Por outro lado, a sua solução é legal porque ela não requer mudanças na arquitetura do sistema de raspagem, e a lógica geral já está feita. Então temos uma vantagem bem grande aí.

[Grisolfi]

@firefueled @gpr-indevelopment

Salve pessoal, tudo bem? Estava lendo o PR aqui e me chamou atenção que o sistema CIGA agrega 291 diários oficiais de Santa Catarina. Isso corresponderia a um crescimento de mais de 50% no numero de municipios do QD.

Acabei encontrando outro estado que centraliza DOMs.

Ja o Famem por essa pagina aqui quase 100, o que tambem geraria um bom crescimento dos indices de % municipios, area e habitantes.

Entendo que estamos falando de uma disrupção no padrão que a plataforma coleta dados, mas me parece se pagar pelo beneficio obtido. Me coloco a disposição para ajudar numa eventual refatoração

PS: Encontrei uma plataforma que parece juntar muita coisa aqui... Não cheguei avaliar quantidade de municipios, mas parece uma tendencia essa união de municipios menores usando essa plataforma -> https://www.diariomunicipal.com.br/

Ex: RS: https://www.diariomunicipal.com.br/famurs/