EquipeDadosAbertosCD
commented
8 years ago Olá, Urbano!
Acredito que você tenha encontrado uma limitação dos nossos webservices -- na verdade, não deles, mas do próprio modelo de dados adotado em algumas aplicações da Câmara. Fiz um teste aqui e descobri que o XML retornado tem sempre o atributo "ano" com o valor "0" para (pelo menos) os seguintes tipos de proposição:
- ADD (Adendo)
- ANEXO
- CVO (Complementação de Voto)
- DTQ (Destaque)
- DVT (Declaração de Voto)
- PRL (Parecer do Relator)
- RLF (Relatório Final)
- RLP (Relatório Prévio)
- RRL (Relatório do Relator)
- SBT (Substitutivo)
- SBR (Subemenda de Relator)
- VTS (Voto em Separado)
O que há em comum entre todos estes tipos de proposição é que eles não "existem por conta própria". São todos dependentes de alguma outra proposição. Isso é o que leva a crer que se trata de uma característica da nossa modelagem interna dos dados, que não considerou estes tipos como, digamos, "proposições de primeiro nível".
Dependendo da natureza da aplicação, uma solução seria, como você tentou, fazer um "parse" do nó <DataApresentacao> para extrair o ano. Isso serviria para exibição da proposta, mas não para uma nova pesquisa -- provavelmente pelo fato de o mecanismo de busca da base de dados não ser capaz de encontrar um registro com o campo "ano" com valor "0". E esse registro é criado não pelos webservices, mas pelas aplicações internas da Câmara que alimentam a base de dados.
Não sei se consegui depreender exatamente o que a sua aplicação necessita. Se entendi direito, a solução seria usar o mesmo ObterProposicaoPorId para obter os dados da proposição principal (o código dela está no nó <idProposicaoPrincipal>). Aí, teoricamente, talvez você pudesse obter os detalhes da tramitação de todas as proposições "anexas" usando o serviço ObterRegimeTramitacaoDespacho -- mas este está reconhecida e assumidamente quebrado e não temos ainda perspectiva de quando poderemos arrumá-lo.
Não obstante, sua sugestão de uniformizar os parâmetros para busca entre os diversos serviços é uma das prioridades na remodelagem dos Dados Abertos, que pretendemos implementar o mais brevemente possível.
Obrigado e abraço!
Fabricio Rocha Cenin
urbanobm
lucasmation
boa tarde!
Descobri uma anomalia em quase 1/3 das matérias que consultei. Elas estão sem o ano, o valor está retornando "0" apesar de terem a data de apresentação preenchida e também terem um dado de ano no campo "nomeproposicao". Mesmo utilizando um dos valores de ano, seja o ano da data de apresentação ou o ano do nme da proposição o retorno não é o correto. Segue um exemplo:
Código: CD.2086817 Ano: "0" Data apresentação: 2016-06-07 Referência: RL 3 CCJC => PL 7801/2010
URL para consulta utilizando o código: http://www.camara.gov.br/SitCamaraWS/Proposicoes.asmx/ObterProposicaoPorID?idProp=2086817
Se utilizarmos os dados retornados na consulta por código na consulta de comissões, por exemplo, dá o erro “Missing parameter: ano.”. Segue a URL: http://www.camara.gov.br/SitCamaraWS/Orgaos.asmx/ObterIntegraComissoesRelator?tipo=PRL&numero=3&ano
Se usarmos o ano da data de apresentação dá o erro “Proposicao inexistente.”. Segue a URL: http://www.camara.gov.br/SitCamaraWS/Orgaos.asmx/ObterIntegraComissoesRelator?tipo=PRL&numero=3&ano=2016
Se usarmos o ano da data de apresentação dá também o erro “Proposicao inexistente.”. Segue a URL: http://www.camara.gov.br/SitCamaraWS/Orgaos.asmx/ObterIntegraComissoesRelator?tipo=PRL&numero=3&ano=2016
Sendo assim, não consigo obter destas matérias os dados de tramitações e de despachos, visto que os WebServices para consultar estes dados não tem a opção de consulta por código da proposição.
Vejo duas formas de resolver o problema. Uma solução seria passar a retornar o ano em todas as consultas de proposições. Outra seria criar uma opção de consulta passando somente o código da proposição para todos as consultas existentes atualmente que exigem os três parâmetros: "tipo", "numero" e "ano".