Dados do Diário Oficial da União serão publicados em formato aberto

open-data
diários-oficiais

#21

Olá @fcatae, muito prazer! Vejo que você e a Microsoft-Brasil arregaçaram as mangas, que boa notícia.

Adquirimos uma certa experiência com o projeto do Domingos, baseado no Poppler… Acho que vale agendar com interessados (me incluo) um Hangout (Appear.in ou outro que não seja Skype) para um primeiro alinhamento e avaliar como podemos ajudar. Temos sugestões também de geração de dados intermediários para auditoria, integridade e controle da qualidade.


@odanoburu, sobre o que comentou,

a questão então é que dados e em que quantidade serão publicados pela IN (i.e., só os de 2016 pra cá, talvez?)

Acho que o @fcatae responde em parte:

  • O “conteúdo gêmeo” das matérias (HTML+PDF) tem sua origem num XML, e esse XML está já disponível abertamente no link indicado. Dá para fazer muita coisa interessante com isso, e até convido interessados a apoiarem montagem de um servidor para análises estatísticas e testes com conversões XSLT.
    Sim, por hora é limitado ao período de produção HTML, que iniciou ano passado.

  • A “conversão retrospectiva para XML” é o desafio que o Fabrício mostra no Github. Precisa converter todo o legado de PDFs em XMLs… Vai depender dos benchmarks para termos uma ideia de quanto pode ser produzido com essa ferramenta-MS sem interferência humana… Imagino que possam ir soltando aos poucos os XMLs de documentos antigos mais simples, tais como portarias. O uso de recursos humanos na conversão assistida tem custo alto, vai depender de existir algum orçamento federal para isso.
    PS: chega uma hora que o processo de conversão é mais simples usando ferramentas de OCR, e a interação humana no processo é o mesmo tipo. Eventualmente o “Azure Cognitive Services” aprenderia com exemplos, e passaria fazer um papel quase humano: estou também curioso para ver :wink:


#22

Desculpa pela demora para responder (a notificação acabou caindo em spam).

Vamos marcar uma conversa sim. Acho que vai ser importante entender o que vocês já fizeram. Toda ajuda aqui é importante.

Infelizmente não acredito que seja possível fazer a conversão 100% automatizada. Um problema que temos agora é como fazer a validação dos documentos, que seria a “operacionalização da conversão assistida”. Por enquanto, estou trabalhando em um WebServer para expor os dados de forma mais simples ao usuário.

Abraços, Fabricio


#23

Olá @fcatae! Aproveitei a sua resposta para entrar em contato com o Domingos, que, neste momento é a pessoa-chave aqui do nosso antigo grupo de interesse, para indicar para vocês o melhor caminho, inclusive na validação e avaliação (diff TXT) das suas conversões.

Aqui vai também um relatório geral da situação, a quem possa interessar.


… Das pessoas que colocaram a mão na massa no início de 2017, nenhuma se encontra disponível, serão apenas palpites e dicas quando conversarmos… O Domingos agora está na Espanha, o Marcos no Vietnã e eu comprometido com outros projetos, fora da OKBR.
Outras pessoas como o Andrés, que implementou o Diário Livre, estão também já comprometidas com outras iniciativas fora da OKBR. Sugiro contato com o Andrés para avaliar aspectos do entregável intermediário que você produzir, e das imperfeições tidas como aceitáveis em aplicações de utilidade pública.

Enfim, mesmo para dar dicas temos um probleminha de contexto (você precisa nos relembrar e dar exemplos) e de fuso horário. A Espanha este mês ainda estará 5 horas na nossa frente. Envie e-mail e tentamos sincronizar.

Quem mais quiser está convidado (!), podemos anunciar aqui no Discuss a hora e link da videoconferência.


Comentários e sugestões do Domingos — em email diz que topa a videoconferência se ajustarmos um horário razoável:

Em quanto ao que eu fiz para remapear os “text encodings” dos PDFs que lo omitem, sim podem resolver uma grande parte desses PDFs.

Em linhas gerais (…) se trata de usar o programa fontforge para gerar uma base de dados com os “character encodings” en formato ASCII e fazer o mesmo com os “font subsets” que vem nos PDFs sem “text encoding maps”, e gerar o “text encoding map” e inserir no PDF para então gerar o texto con opdftotext (poppler) ou outro semelhante.

Este último passo, tentar reconstruir um TXT fiel ao PDF porém livre das colunas de diagramação, foi o objetivo maior e motivação do trabalho do Domingos. Chegou aos ~80% conversão sem falhas no DOU e DOM-SP.


Com 100% de automação, todavia, ficamos um passo antes: o trabalho do Domingos já permite recriar um PDF com char-encode resolvido, e, de brinde, uma das saídas do Poppler (adaptada por ele) gera também algo semelhante a um dump em arquivo CSV (cada PDF internamente é uma tabela de texto-posição).
… Em função disso houve a sugestão de armazenar esse dump de conteúdo fiel em SQL, ao invés de jogar de volta para PDF ou TXT. Propusemos uma arquitetura para o SQL (no PostgreSQL tem opção JSONb-SQL) gerar visualização HTML on-the-fly, buscas, estatísticas, etc. com garantia de fidelidade.


#24

Pessoal eu gostaria muito de participar! Eu nunca trabalhei em nenhum projeto sobre “leitura” de pdf, mas trabalho com scraping e mineração de dados de portais públicos e me interesso bastante por projetos em dados governamentais abertos. Se possível, compartilhem as informações aqui, por favor.

Bons Ventos! Lucas Armand.