Colocando dados no OpenSpending

[Andres MRM]

Fui dar uma olhada em como colocarmos nossos dados no OS.
Para ajudar ele parece estar DOWN nesse momento...
Mas achei esse tutorial sobre como criar um budget data package, que acho que
é o padrão que você tinha dito, não Edgar?
http://community.openspending.org/2014/10/how-to-create-a-budget-data-package/

Em uma parte ele fala de colocar as funções seguindo o padrão COFOG:
http://unstats.un.org/unsd/cr/registry/regcst.asp?Cl=4
Que aparentemente não é o que temos nos nossos dados. O padrão brasileiro
parece estar descrito aqui:
http://www.orcamentofederal.gov.br/informacoes-orcamentarias/manual-tecnico/MTO_2014_290713.pdf
(pag 157 em diante)
E converter de um padrão para outro parece requerer um pouco de domínio do
assunto. Não achei essa conversão já feita na net...
Como fazemos? Ignoramos esse padrão por enquanto, ou tentamos fazer nós mesmos
a conversão?

[Andres MRM]

Falei com o trickvi no IRC, ele "ressuscitou" o OpenSpending. Falou também que
para criar um budget data package precisa mesmo seguir o COFOG, mas eles
pretendem, no futuro, deixar o padrão menos rígido para não exigir isso.
Logo não sei se compensa convertermos...

Estou começando o código para lidarmos com a API via Python, pois perguntei
para o trickvi e ele disse que ainda não existe uma lib para isso, mas que
ficaria muito feliz se fizéssemos uma. =P Então estou tentando deixar genérico
o bastante para, quem sabe, virar o começo de uma lib.


Quoting Andres MRM (2014-12-14 17:00:10)

[Edgar Zanella Alvarenga]

On 14/12/2014 21:39, Andres MRM wrote:
> Falei com o trickvi no IRC, ele "ressuscitou" o OpenSpending. Falou
> também que
> para criar um budget data package precisa mesmo seguir o COFOG, mas
> eles
> pretendem, no futuro, deixar o padrão menos rígido para não exigir
> isso.
> Logo não sei se compensa convertermos...

Tinha visto a conversa antes no canal #openspending. Quanto ao COFOG eu
pensei
ser possível utilizar meta dados extras para os campos que possuíssemos
e
estivésse fora do padrão COFOG. O problema está nos campos que
precisarão ser
mapeados. Não analisei em detalhes campo a campo, mas será mesmo que
isso
vai dar muito trabalho? Mas em primeiro lugar, vamos ganhar alguma
coisa
fazendo isso?

A única vantagem de fazermos esse trabalho agora seria que poderíamos
transformar
os dados de outras prefeituras para esse padrão e ter nossas futuras
visualizações
funcionando sem precisar nenhuma modificação no código.

> Estou começando o código para lidarmos com a API via Python, pois
> perguntei
> para o trickvi e ele disse que ainda não existe uma lib para isso,
> mas que
> ficaria muito feliz se fizéssemos uma. =P Então estou tentando deixar
> genérico
> o bastante para, quem sabe, virar o começo de uma lib.

Lidar com API do openspending? Exatamente pra que?

E

[Edgar Zanella Alvarenga]

Outra coisa: essa instabilidade do OpenSpending é algo sério e pra mim
nossos dados deverão ficar hospedados em outro lugar. Podemos até
colocar
os dados lá, mas não é a primeira vez que vejo o OpenSpending saindo do
ar. Ok, o serviço é gratuito então não posso reclamar muito, mas que é
amador isso é. 16Gb de memória não é nada pra um servidor que pretenda
hospedar centenas de bases de dados diferentes.

On 14/12/2014 21:39, Andres MRM wrote:

[Edgar Zanella Alvarenga]

On 14/12/2014 17:00, Andres MRM wrote:
> Fui dar uma olhada em como colocarmos nossos dados no OS.
> Para ajudar ele parece estar DOWN nesse momento...
> Mas achei esse tutorial sobre como criar um budget data package, que
> acho que
> é o padrão que você tinha dito, não Edgar?
>
> http://community.openspending.org/2014/10/how-to-create-a-budget-data-package/

Isso aí, era esse mesmo.

> Em uma parte ele fala de colocar as funções seguindo o padrão COFOG:
> http://unstats.un.org/unsd/cr/registry/regcst.asp?Cl=4
>
> Que aparentemente não é o que temos nos nossos dados. O padrão
> brasileiro
> parece estar descrito aqui:
>
> http://www.orcamentofederal.gov.br/informacoes-orcamentarias/manual-tecnico/MTO_2014_290713.pdf
> (pag 157 em diante)
>
> E converter de um padrão para outro parece requerer um pouco de
> domínio do
> assunto. Não achei essa conversão já feita na net...
> Como fazemos? Ignoramos esse padrão por enquanto, ou tentamos fazer
> nós mesmos a conversão?

Exato, não é o padrão seguido pelo brasileiro e pensando melhor agora
acho que
devemos discutir sobre uma possível mudança de prioridade no
cronograma. Ao invés
de começarmos pela importação dos dados para o OpenSpending, talvez
seja melhor
já iniciarmos o processo de coletar e limpar todos os dados de Receita
e as
visualizações deles.

Na maior parte das visualizações acredito que teremos um processamento
prévio dos
dados para transformá-lo num conjunto bem menor. Para isso poderemos
transformar
os dados via Python e os resultados ficarão em outras planilhas, json
ou em um
banco de dados se necessário.

Por exemplo, imagine nas visualizações por subprefeitura, agrupados por
funções. Não
faz sentido que toda hora façamos um query dos dados filtrando por um
campo e somemos
agrupando por função. Podemos simplesmente criar um novo CSV contendo
tais
agrupamentos.

E

[Andres MRM]

>Lidar com API do openspending? Exatamente pra que?

Num primeiro momento para submeter dados. Imagino que a criação e atualização
dos datasets será feita via Python, não?

>Exato, não é o padrão seguido pelo brasileiro e pensando melhor agora acho
>que devemos discutir sobre uma possível mudança de prioridade no cronograma.
>Ao invés de começarmos pela importação dos dados para o OpenSpending, talvez
>seja melhor já iniciarmos o processo de coletar e limpar todos os dados de
>Receita e as visualizações deles.

Eu estava pensando em começar por uma visualização, mas pensei que a parte de
entrada dos dados na visualização depende da fonte que iremos usar, no caso, o
OpenSpending. Então comecei por ele, como está no cronograma.
Você pensa em não pegarmos os dados direto dele para as visualizações então?

>Na maior parte das visualizações acredito que teremos um processamento prévio
>dos dados para transformá-lo num conjunto bem menor. Para isso poderemos
>transformar os dados via Python e os resultados ficarão em outras planilhas,
>json ou em um banco de dados se necessário.

Parece uma boa. Só não sei o quanto vamos conseguir juntar as planilhas...
Como por exemplo o Quadro Detalhado e o Projeto de Lei, que comentei no outro
e-mail. O máximo que parece que dá para fazer é relacionar um conjunto com
outro.

>Por exemplo, imagine nas visualizações por subprefeitura, agrupados por
>funções. Não faz sentido que toda hora façamos um query dos dados filtrando
>por um campo e somemos agrupando por função. Podemos simplesmente criar um
>novo CSV contendo tais agrupamentos.

Acho que entendi só mais ou menos. Você está defendendo deixarmos os dados
pré-agrupados e disponíveis para o código JS só baixar? Por mim ótimo.


Vamos ter mesmo uma reunião amanhã? Para mim ficou melhor terça. Umas 10h ou a
partir das 13h.



Quoting Edgar Zanella Alvarenga (2014-12-14 22:28:08)

> --
> Você está recebendo esta mensagem porque se inscreveu no grupo "gastosabertos-dev" dos Grupos do Google.
> Para cancelar inscrição nesse grupo e parar de receber e-mails dele, envie um e-mail para gastosabertos-...@googlegroups.com.
> Para postar neste grupo, envie um e-mail para gastosab...@googlegroups.com.
> Para ver esta discussão na web, acesse https://groups.google.com/d/msgid/gastosabertos-dev/7dfcf04a52fb0ac98a922f2d516a75d7%40vaz.io.
> Para obter mais opções, acesse https://groups.google.com/d/optout.

[Edgar Zanella Alvarenga]

On 14/12/2014 23:41, Andres MRM wrote:
>>Lidar com API do openspending? Exatamente pra que?
>
> Num primeiro momento para submeter dados. Imagino que a criação e
> atualização
> dos datasets será feita via Python, não?

Ah tá, só é importante documentarmos antes de qualquer início de
implementação
o que será feito e como, termos uma discussão mínima, pelo menos dentro
do
escopo do Gastos Abertos. Por exemplo, se for pra implementar uma API
em Python
melhor ter um documento antes, no wiki do github ou wikiversidade
descrevendo quais
partes da API vai ser implementada e em qual ordem.

Quanto a importação/atualização dos dados, existirá os seguintes
processos
(marcando o que depende e o que não depende da API do OpenSpending):

Sem API: Pegar os dados novos.

API: Comparar com os dados antigos (eventualmente se estiverem no
OpenSpending será
necessário acessá-los pela API)

Sem API: Ver como as diferenças dos dados serão adicionados aos dados
que já possuímos.
O mais simples é simplesmente guardar uma nova versão dos dados. Pra
melhorar isso
de forma trivial seria salvarmos a versão antiga no repositório para
termos um
histórico. Para melhor isso de forma não trivial, poderíamos pensar em
usar algo como
o https://github.com/maxogden/dat

API: Subir nova versão dos dados pro OpenSpending

> Eu estava pensando em começar por uma visualização, mas pensei que a
> parte de
> entrada dos dados na visualização depende da fonte que iremos usar,
> no caso, o
> OpenSpending. Então comecei por ele, como está no cronograma.
> Você pensa em não pegarmos os dados direto dele para as visualizações
> então?

Isso, vamos avançar depois na importação pro OpenSpending. Por enquanto
processamos
os dados e focamos nas visualizações, mas no processo vamos
automatizando as transformações
dos dados para ficarem gerais o suficiente para serem customizadas para
outros dados
depois.

> Parece uma boa. Só não sei o quanto vamos conseguir juntar as
> planilhas...
> Como por exemplo o Quadro Detalhado e o Projeto de Lei, que comentei
> no outro
> e-mail. O máximo que parece que dá para fazer é relacionar um
> conjunto com
> outro.

Bom, isso vai depender se a visualização necessitar de tal
relacionamento. Se não
necessitar só deixamos documentado em algum lugar tal relação. Se a
necessitar
pensamos em como unicar, seja num banco de dados, ou dois arquivos
csv/json com ids
em comum.

> Acho que entendi só mais ou menos. Você está defendendo deixarmos os
> dados
> pré-agrupados e disponíveis para o código JS só baixar? Por mim
> ótimo.

Isso, entendeu corretamente.

> Vamos ter mesmo uma reunião amanhã? Para mim ficou melhor terça. Umas
> 10h ou a
> partir das 13h.

Então vamos fazer na terça. Qual melhor forma? Ekiga? Firefox WebRTC? G
Hangout? Skype?
E.

[Andres MRM]

Quoting Edgar Zanella Alvarenga (2014-12-15 00:36:19)

> Ah tá, só é importante documentarmos antes de qualquer início de
> implementação
> o que será feito e como, termos uma discussão mínima, pelo menos dentro
> do
> escopo do Gastos Abertos. Por exemplo, se for pra implementar uma API
> em Python
> melhor ter um documento antes, no wiki do github ou wikiversidade
> descrevendo quais
> partes da API vai ser implementada e em qual ordem.

Ok. Por enquanto era só uma classe com um método para criar um dataset no OS,
mas ele está dando erro de acesso não autorizado...

> Quanto a importação/atualização dos dados, existirá os seguintes
> processos
> (marcando o que depende e o que não depende da API do OpenSpending):
>
> Sem API: Pegar os dados novos.

Isso pq os dados são pegos do governo, certo?

> Isso, vamos avançar depois na importação pro OpenSpending. Por enquanto
> processamos
> os dados e focamos nas visualizações, mas no processo vamos
> automatizando as transformações
> dos dados para ficarem gerais o suficiente para serem customizadas para
> outros dados
> depois.

Ok.

> Então vamos fazer na terça. Qual melhor forma? Ekiga? Firefox WebRTC? G
> Hangout? Skype?

Hum, faz tempo que quero testar o FF para isso, podemos tentar. Mas não sei
vai funcionar... Se não podemos ir via Ekiga ou Mumble.

> Para ver esta discussão na web, acesse https://groups.google.com/d/msgid/gastosabertos-dev/8ccc5f5a3d3d9e3925299fcaad56ef48%40vaz.io.