[ANN] LegisDados
10 views
Skip to first unread message
Helder Ribeiro
Oct 22, 2009, 6:46:29 PM10/22/09
to thac...@googlegroups.com, parlamen...@googlegroups.com
Olá pessoal, beleza?
Depois de umas conversas com o Eduardo Leoni resolvemos juntar forças
e criar um projeto spin-off do CongressoAberto e do ParlamentoAberto
chamado LegisDados.
Ambos estávamos repetindo trabalho de raspar os dados da Câmara e
mantendo os scripts dentro da nossa aplicação, sem que houvesse uma
necessidade real pra esse acoplamento.
Por isso criamos o projeto LegisDados com o objetivo de ter um
repositório centralizado de scripts de raspagem de dados relativos ao
Legislativo brasileiro e independentes de aplicação.
No momento eu apenas copiei os scripts que já havia escrito para o
Parlamento Aberto, e o Eduardo fará o mesmo com os scripts do
CongressoAberto. Depois os adaptaremos para se tornarem de propósito
geral e utilizáveis por qualquer um.
O projeto está no github em:
http://github.com/obvio171/legisdados
E a documentação será mantida em:
http://wiki.github.com/obvio171/legisdados
Por enquanto estamos raspando apenas a Câmara Federal, mas pretendemos
fazer o mesmo com o Senado, com todas as Assembléias Legislativas
estaduais e todas as Câmaras Municipais. Tem muito trabalho pra fazer,
então precisamos da sua ajuda :)
Ah, e pra não entulhar nenhuma dessas listas com um monte de emails
sobre os detalhes sórdidos da raspagem, criei uma lista em
http://groups.google.com/group/legisdados para abrigar as discussões
técnicas. Qualquer dúvida é só dar um grito.
Abraços,
Helder Ribeiro
http://helderribeiro.net
http://trac.parlamentoaberto.org
Pedro Markun
Oct 22, 2009, 6:53:14 PM10/22/09
to parlamen...@googlegroups.com, thac...@googlegroups.com
Fabricio Zuardi
Oct 22, 2009, 8:24:47 PM10/22/09
to parlamen...@googlegroups.com
Legal!
Duas sugestões:
1- comitar também os arquivos gerados (csv) no repositório, numa pasta data ou algo do tipo aí o controle de versão serve tanto p/ o código qto p/ os dados. Fica tipo um cache p/ quem não quer ou não precisa rodar tudo de novo p/ obter os dados.
2- seria bom uma tabelinha no wiki dizendo as URLs que os scripts atuais ja cobrem e quais páginas ainda estão sem raspagem implementada, assim quem quiser contribuir tem algumas sugestões de onde ajudar.
[]s
Fabricio C Zuardi
Eduardo Leoni
Oct 22, 2009, 10:00:51 PM10/22/09
to parlamen...@googlegroups.com
2009/10/22 Fabricio Zuardi <fabr...@fabricio.org>
Legal!Duas sugestões:1- comitar também os arquivos gerados (csv) no repositório, numa pasta data ou algo do tipo aí o controle de versão serve tanto p/ o código qto p/ os dados. Fica tipo um cache p/ quem não quer ou não precisa rodar tudo de novo p/ obter os dados.
Concordo. Se não os dados, pelo menos a estrutura dos diretórios de dados. Eu prefiro que a gente crie um "configuration file" que aponte para o path absoluto do diretorio de dados dentro do repositório legisdados. Pode ser assim Helder?
2- seria bom uma tabelinha no wiki dizendo as URLs que os scripts atuais ja cobrem e quais páginas ainda estão sem raspagem implementada, assim quem quiser contribuir tem algumas sugestões de onde ajudar.
Concordo de novo. Podemos ir colocando na wiki http://wiki.github.com/obvio171/legisdados Já comecei.
-eduardo
Eduardo Leoni
Oct 22, 2009, 10:16:30 PM10/22/09
to parlamen...@googlegroups.com
helder -
eu acho que vc tem que abrir o acesso para o pessoal que quer contribuir na wiki. Acabei de perder a tabela que tinha feito com os scripts que a gente já tem. :(
-e
Helder Ribeiro
Oct 23, 2009, 8:24:26 AM10/23/09
to parlamen...@googlegroups.com
2009/10/22 Fabricio Zuardi <fabr...@fabricio.org>:
dados no repositório, ele vai ficar muito grande muito rápido,
principalmente quando começarmos a raspar proposições, emendas, etc.
Isso vai não só atrapalhar quem quiser clonar o repositório pra
desenvolver, mas vai também estourar a quota de 300mb de hospedagem do
Github (que é um limite "soft", mas mesmo assim não é bom abusar).
De um modo geral, em qualquer projeto de software, recomenda-se não
botar no repositório nada que possa ser gerado a partir de coisas que
já estão no repositório (como binários, etc.).
Mas a idéia é prover, sim, os dados já raspados, até porque o site da
câmara é meio fraquinho e vira e mexe o banco de dados deles
(microsoft sql server) dá time out. Assim que tiver um tempinho e os
scripts estiverem um pouco mais estáveis eu hospedo os dados em algum
lugar fácil de baixar, mantendo-os atualizados (tipo um govtrack.us,
só que sem todas as páginas; só um esquema meio rsync + API mesmo).
> Legal!
> Duas sugestões:
> 1- comitar também os arquivos gerados (csv) no repositório, numa pasta data
> ou algo do tipo aí o controle de versão serve tanto p/ o código qto p/ os
> dados. Fica tipo um cache p/ quem não quer ou não precisa rodar tudo de novo
> p/ obter os dados.
Acho que isso é legal de fazer fora do repositório. Se comitarmos os
> Duas sugestões:
> 1- comitar também os arquivos gerados (csv) no repositório, numa pasta data
> ou algo do tipo aí o controle de versão serve tanto p/ o código qto p/ os
> dados. Fica tipo um cache p/ quem não quer ou não precisa rodar tudo de novo
> p/ obter os dados.
dados no repositório, ele vai ficar muito grande muito rápido,
principalmente quando começarmos a raspar proposições, emendas, etc.
Isso vai não só atrapalhar quem quiser clonar o repositório pra
desenvolver, mas vai também estourar a quota de 300mb de hospedagem do
Github (que é um limite "soft", mas mesmo assim não é bom abusar).
De um modo geral, em qualquer projeto de software, recomenda-se não
botar no repositório nada que possa ser gerado a partir de coisas que
já estão no repositório (como binários, etc.).
Mas a idéia é prover, sim, os dados já raspados, até porque o site da
câmara é meio fraquinho e vira e mexe o banco de dados deles
(microsoft sql server) dá time out. Assim que tiver um tempinho e os
scripts estiverem um pouco mais estáveis eu hospedo os dados em algum
lugar fácil de baixar, mantendo-os atualizados (tipo um govtrack.us,
só que sem todas as páginas; só um esquema meio rsync + API mesmo).
Helder Ribeiro
Oct 23, 2009, 8:25:31 AM10/23/09
to parlamen...@googlegroups.com
2009/10/23 Eduardo Leoni <e.l...@gmail.com>:
tem. Valeu a ajuda :) No momento tem duas páginas aparentemente
redundantes: "UsandoScripts" e "Páginas". Ia ser legal consolidá-las
em uma só.
> helder -
> eu acho que vc tem que abrir o acesso para o pessoal que quer contribuir na
> wiki. Acabei de perder a tabela que tinha feito com os scripts que a gente
> já tem. :(
O wiki é aberto. Vi que vocês conseguiram criaram páginas com o que já
> eu acho que vc tem que abrir o acesso para o pessoal que quer contribuir na
> wiki. Acabei de perder a tabela que tinha feito com os scripts que a gente
> já tem. :(
tem. Valeu a ajuda :) No momento tem duas páginas aparentemente
redundantes: "UsandoScripts" e "Páginas". Ia ser legal consolidá-las
em uma só.
Helder Ribeiro
Oct 23, 2009, 8:27:10 AM10/23/09
to parlamen...@googlegroups.com
2009/10/23 Helder Ribeiro <hel...@gmail.com>:
ele pra nada).
> 2009/10/22 Fabricio Zuardi <fabr...@fabricio.org>:
>> Legal!
>> Duas sugestões:
>> 1- comitar também os arquivos gerados (csv) no repositório, numa pasta data
>> ou algo do tipo aí o controle de versão serve tanto p/ o código qto p/ os
>> dados. Fica tipo um cache p/ quem não quer ou não precisa rodar tudo de novo
>> p/ obter os dados.
>
> Acho que isso é legal de fazer fora do repositório. Se comitarmos os
> dados no repositório, ele vai ficar muito grande muito rápido,
> principalmente quando começarmos a raspar proposições, emendas, etc.
> Isso vai não só atrapalhar quem quiser clonar o repositório pra
> desenvolver, mas vai também estourar a quota de 300mb de hospedagem do
> Github (que é um limite "soft", mas mesmo assim não é bom abusar).
>
> De um modo geral, em qualquer projeto de software, recomenda-se não
> botar no repositório nada que possa ser gerado a partir de coisas que
> já estão no repositório (como binários, etc.).
>
> Mas a idéia é prover, sim, os dados já raspados, até porque o site da
> câmara é meio fraquinho e vira e mexe o banco de dados deles
> (microsoft sql server) dá time out. Assim que tiver um tempinho e os
> scripts estiverem um pouco mais estáveis eu hospedo os dados em algum
> lugar fácil de baixar, mantendo-os atualizados (tipo um govtrack.us,
> só que sem todas as páginas; só um esquema meio rsync + API mesmo).
Registrei, a propósito, o domínio legisdados.org (ainda não direcionei
>> Legal!
>> Duas sugestões:
>> 1- comitar também os arquivos gerados (csv) no repositório, numa pasta data
>> ou algo do tipo aí o controle de versão serve tanto p/ o código qto p/ os
>> dados. Fica tipo um cache p/ quem não quer ou não precisa rodar tudo de novo
>> p/ obter os dados.
>
> Acho que isso é legal de fazer fora do repositório. Se comitarmos os
> dados no repositório, ele vai ficar muito grande muito rápido,
> principalmente quando começarmos a raspar proposições, emendas, etc.
> Isso vai não só atrapalhar quem quiser clonar o repositório pra
> desenvolver, mas vai também estourar a quota de 300mb de hospedagem do
> Github (que é um limite "soft", mas mesmo assim não é bom abusar).
>
> De um modo geral, em qualquer projeto de software, recomenda-se não
> botar no repositório nada que possa ser gerado a partir de coisas que
> já estão no repositório (como binários, etc.).
>
> Mas a idéia é prover, sim, os dados já raspados, até porque o site da
> câmara é meio fraquinho e vira e mexe o banco de dados deles
> (microsoft sql server) dá time out. Assim que tiver um tempinho e os
> scripts estiverem um pouco mais estáveis eu hospedo os dados em algum
> lugar fácil de baixar, mantendo-os atualizados (tipo um govtrack.us,
> só que sem todas as páginas; só um esquema meio rsync + API mesmo).
ele pra nada).
Eduardo Leoni
Oct 23, 2009, 11:00:41 AM10/23/09
to parlamen...@googlegroups.com
Acho que isso é legal de fazer fora do repositório. Se comitarmos os
dados no repositório, ele vai ficar muito grande muito rápido,
principalmente quando começarmos a raspar proposições, emendas, etc.
Isso vai não só atrapalhar quem quiser clonar o repositório pra
desenvolver, mas vai também estourar a quota de 300mb de hospedagem do
Github (que é um limite "soft", mas mesmo assim não é bom abusar).
Os scripts assumem uma certa estrutura dos diretórios. Por isso acho que poderíamos apontar os dados para um diretório dentro do repositório, mas fazer o git ignorar os arquivos de dados. Just a thought.
Helder Ribeiro
Oct 23, 2009, 11:41:57 AM10/23/09
to parlamen...@googlegroups.com
2009/10/23 Eduardo Leoni <e.l...@gmail.com>:
Então, isso é um problema momentâneo dos scripts, só porque eu os
transplantei direto do Parlamento Aberto. Eles assumem a estrutura de
diretórios de uma aplicação rails, mas isso é arbitrário.
Mas eu vou alterá-los pra não dependerem de estrutura de diretórios.
Eles devem criar os dados no diretório atual se nada for especificado,
e devem poder receber um parâmetro de linha de comando especificando
(opcionalmente) onde os dados devem ser guardados.
> >
>
transplantei direto do Parlamento Aberto. Eles assumem a estrutura de
diretórios de uma aplicação rails, mas isso é arbitrário.
Mas eu vou alterá-los pra não dependerem de estrutura de diretórios.
Eles devem criar os dados no diretório atual se nada for especificado,
e devem poder receber um parâmetro de linha de comando especificando
(opcionalmente) onde os dados devem ser guardados.
> >
>
Helder Ribeiro
Oct 23, 2009, 11:43:19 AM10/23/09
to parlamen...@googlegroups.com
2009/10/23 Helder Ribeiro <hel...@gmail.com>:
Escrevi isso melhor aqui:
http://wiki.github.com/obvio171/legisdados/escrevendoscripts
São as linhas gerais que eu alterarei os scripts atuais pra obedecerem.
>
>> >>
>>
>
http://wiki.github.com/obvio171/legisdados/escrevendoscripts
São as linhas gerais que eu alterarei os scripts atuais pra obedecerem.
>
>> >>
>>
>
Reply all
Reply to author
Forward
0 new messages