O postgis tem as funções "ST_AsGeoJSON" que devolve um geojson e "ST_GeomFromGeoJSON" que devolve um objeto de geometria do postgis a partir de um geojson.
2015-07-07 10:29 GMT-03:00 Andres MRM <[email protected]>: > > Falei uma semana pensando em trabalho extra por abandonar > MongoDB+PythonEve. > Há coisas que já precisariam ser feitas de qualquer jeito (como a > padronização > de todos os anos dos dados de execução, que fiz semana passada). Mas sim, é > possível que o custo extra total por se adotar PostGIS no lugar de MongoDB > seja maior que uma semana... Ou não. É difícil estimar... > > Não sabia que PostGIS também suporta GeoJSON, depois vejo se o GeoAlchemy > já > implementou isso. > > > Quoting Luiz Armesto (2015-07-07 09:44:10) > > A minha proposta é que discussão de questões técnicas sejam feitas na > lista > > gastosabertos [1]. > > > > Os issues do Github ficam para descrição de tarefas. Sempre que alguém > for > > realizar qualquer tarefa, deve ter um ticket aberto, com a descrição do > que > > será feito e assinado para aquela pessoa. Seja uma tarefa de > desenvolvimento, > > de administração de servidor, de pesquisa por soluções técnicas... Assim > > evitamos trabalho duplicado e sabemos o que cada um está fazendo. (vou > abrir > > uma outra thread na lista do gastosabertos para conversarmos sobre como > nos > > organizarmos, esperem para responder esse ponto nela) > > > > Sobre a migração do cuidando para o gastosabertos, uma semana é > suficiente > > mesmo? Na minha opinião não basta passar a salvar os dados que eram > salvos na > > base de dados do cuidando em mongodb na base de dados do gastosabertos. > Tem que > > fazer realmente a utilização das funcionalidades de indexação espacial do > > postgis, visto que atualmente os valores de longitude e latitude do > cuidando > > são salvos como simples colunas float. Os dados de geolocalização não > devem ser > > contaminados com códigos de erro, então nada de "404" para representar > valores > > que não foi possível fazer o geocoding. O formato intermediário para os > valores > > de geolocalização deve seguir um padrão, de preferencia geojson que é > suportado > > tanto pelo postgis quanto pelo leaflet. > > > > > > [1] https://lists.okfn.org/mailman/listinfo/gastosabertos > > > > 2015-07-07 8:03 GMT-03:00 Andres MRM <[email protected]>: > > > > > > Bom dia Peter, > > > > Eu tinha dito uma semana para a migração de todos os dados. Por > enquanto > > migrei só a receita e os contratos (que eram os que estavam em MySQL > e nem > > estavam na conta inicial, já que eu achava que eles estavam em > Postgres). > > Nesse momento estou cuidando da migração da execução. Mas aquele > prazo de > > uma > > semana (depois eu percebi que não fui bem claro) era pensando não só > nessa > > migração inicial (que deve levar menos tempo), mas também o custo a > mais de > > desenvolvimento quando realmente for usar o PostGIS, ou precisar > adicionar > > novas funcionalidades que PythoEve+MongoDB já davam "de graça". > > > > Sobre a doc, realmente precisamos definir melhor isso... Vamos tentar > > pensar: > > O que documentar e onde? > > > > - Mais especificamente sobre os dados que usamos (que eu até fui meio > > chatinho > > com você quanto a isso), a documentação está centralizada aqui: > > https://pt.wikiversity.org/wiki/Gastos_Abertos/Prot%C3%B3tipo > > - Doc da API. Por enquanto está na wiki GitHub do GA, mas em algum > momento > > ela > > será gerada automaticamente em outro lugar. > > - Doc de instalação. Estou tentando registrar os passos necessários > para > > instalar o projeto, mas isso ainda não está consolidado. Ficaria no > > repositório. > > - Documento sobre como contribuir, na linha do que o Raniere propôs. > Esse > > precisamos pensar melhor como fazer... Ficaria no repositório > também? É > > só > > para quem programa? E quem não programa e quer contribuir? > > - Descrição sobre o projeto. Eu consigo pensar em uma parte mais > técnica e > > outra mais geral. No Cuidando estou deixando na Wiki do > GitLab/GitHub. > > Mas > > seria bom pensar qual o mínimo de coisas que ela tem que ter. > > > > - O que mais precisaria ser documentado/consolidado? > > > > > > Depois a parte de comunicação... Estou enviando os e-mails todos para > > GA+OK-Br porque foi isso que entendi que era para fazer. E de certa > forma > > acho > > bacana porque vira e mexe aparece alguma pessoa nova comentando. Mas > se > > acharem que é muito SPAM, por mim podemos mudar. > > > > > > Abs! > > > > > > > > Quoting Peter Krauss (2015-07-07 07:31:37) > > > Bom dia Andres, > > > > > > A estimativa era (até onde lembro pois não consta em ata ou > trello) de > > que o > > > processo de migração para PostgreSQL v9.3+ > > > tomasse no máximo uma semana de trabalho... > > > Pelo que estou vendo, tomou só um dia (!) e, a menos de testes e > > feedbacks da > > > equipe, está feito... > > > Parabéns! > > > > > > - - - - > > > Nota geral (Bom dia a todos do Gastos+Cuidando!), > > > sobre "probleminhas técnicos presentes e futuros": onde é melhor > > discuti-los? > > > > > > Pelo que entendi isso tudo agora é responsabilidade do Gastos > Abertos > > (nada de > > > dados cadastrais no Cuidando), então temos: > > > * Lista geral da OKBr (aqui [email protected]) > > > * Lista do Gastos ([email protected]) > > > * github.com/okfn-brasil/gastos_?? (/issue ou /wiki?) > > > * Wiki geral do Gastos > > > * (...difícil decidir onde...) > > > > > > Onde a equipe Gastos julga que é melhor fazer a discussão > "altamente > > técnica" > > > da coisa? > > > Não teria como "criar regra" para evitar de poluir canal > inadequado, e de > > > ninguém mais ficar perdido? > > > > > > - - - - > > > PS1: o Cuidando2 tem como foco os dados geocodificados, mas se a > > geocodificação > > > é também responsabilidade do Gastos, então o Cuidando2 nem precisa > cuidar > > > disso.... Ainda assim, existem demandas comuns sob > responsabilidade do > > > Cuidando2, a arquitetura de web-services e protocolo de > autenticação > > estavam > > > sendo discutidos na equipe do Cuidando2... > > > > > > PS2: a deliberações da "cúpula do Gastos+Cuidando" deveriam ser > > registradas em > > > ATA (no link é um rascunho aguardando revisão dos participantes da > > reunião). > > > ...Estou imaginando/supondo da reunião, que as especificações > funcionais > > e > > > requisitos do "escopo arquitetura" seriam responsabilidade do > Cuidando2. > > > > > > > > > > > > Em 6 de julho de 2015 19:45, Andres MRM <[email protected]> > escreveu: > > > > > > > > > Migrei os dados atuais do GA para o Postgres. Aparentemente > está > > > funcionando: > > > http://gastosabertos.org/receitas > > > http://demo.gastosabertos.org/contratos > > > (Havia um probleminha de ints que passaram a ser floats e > apareceram > > assim > > > na interface. Arrumei, mas pode ter outras falhas que não vi.) > > > Vamos se assim para o erro aleatório que estava dando também... > > > > > > Luiz e Edgar, importei os contratos usando o > "import_contrato.py". O > > > "import_contrato_urls.py" não consegui fazer funcionar, não > sei se > > era para > > > usá-lo também, mas pelo que vi o site está normal. > > > Mudei a pasta da instância para a home. Espero que assim não dê > > problema > > > caso > > > a máquina seja reiniciada... > > > > > > > > > Quoting Peter Krauss (2015-07-06 13:00:04) > > > > A minha proposta é a mesma de antes (falta definirmos Wiki's > links > > > perdidos), e > > > > me parece compatível com o seu levantamento: > > > > > > > > * sem pensar: <ID, JSON> ou <ID, TEXT[]> ou seja, "FLEX"; > > > > > > > > * pensando (planejando o conjunto completo de dados, se > surgirem > > demandas > > > joins > > > > e indexações): <ID, chave1, chave2, restoFLEX> > > > > > > > > O segundo parece mais chatinho, mas tem como automatizar no > > PostgreSQL. > > > > > > > > > > > > > > > > > > > > Em 6 de julho de 2015 11:46, Andres MRM < > [email protected]> > > escreveu: > > > > > > > > > > > > Dei um "apt-get -f install" que aparentemente arrumou as > > dependências > > > do > > > > MariaDB. > > > > > > > > Consegui então instalar o Postgres 9.4 seguindo isso > aqui: > > > > http://www.postgresql.org/download/linux/ubuntu/ > > > > Vou ver agora se migro os dados do GA para ele e começo a > > colocar os > > > novos > > > > dados de execução nele também. > > > > > > > > Sobre esses últimos conversei no canal do IRC do > SQLAlchemy > > sobre a > > > questão > > > > e > > > > me recomendaram ou usar uma coluna no BD para cada > coluna da > > planilha > > > > (mesmo > > > > que várias delas vazias para alguns anos) ou usar o tipo > JSON. > > Ainda > > > não > > > > sei, > > > > mas acho que vou pelo JSON... > > > > > > > > > > > > Quoting Peter Krauss (2015-07-03 13:10:33) > > > > > > > > > > > > > > > Em 3 de julho de 2015 12:33, Andres MRM < > [email protected] > > > > > > escreveu: > > > > > > > > > > > > > > > Quoting Peter Krauss (2015-07-03 11:57:28) > > > > > > O primeiro para o coletivo aqui poder ajudar é > > documentar: > > > se > > > > precisar > > > > > ajudo, > > > > > > sugiro na > > > > > > https://github.com/okfn-brasil/cuidando2/wiki > > > > > > é fundamental saber o perfil dessas tabelas > (cabeçalho > > de > > > colunas > > > > basta), > > > > > e ter > > > > > > uma legenda no que for relevante. > > > > > Basicamente são Integers e Strings. Mas tem datas > também, > > menos > > > > relevantes. > > > > > > > > > > > Em seguida entender o que seria "chave primária" > > (candidatos) > > > de > > > > cada > > > > > uma, para > > > > > > avaliarmos se ao menos isso foi preservado ao > longo dos > > anos. > > > > > As colunas basicamente são códigos (int) e a > descrição de > > cada > > > código > > > > > (str). > > > > > Aparentemente todos esses códigos são necessários > para > > > construir uma > > > > chave > > > > > primária. Um jeito seria construir uma str que é a > > somatória de > > > todos > > > > esses > > > > > ints e colocar em uma nova coluna: > > > > > > > > > > 2015.23.49.8787.73898798 > > > > > > > > > > Mas, como disse antes, o número de códigos varia > ao longo > > dos > > > anos, > > > > então > > > > > algumas chaves seriam compostas por mais ou menos > ints. > > > > > > > > > > > > > > > Se tá difícil documentar na Wiki, pode ser um simples > Excel > > > (GoogleDocs) > > > > > mostrando exemplo dos cabeçalhos (não interessa tanto > o tipo > > do > > > valor mas > > > > ter > > > > > uma ideia da semântica para consolidar as > chaves-candidatas > > ... Eu > > > > costumo > > > > > documentar com uma linha de cabeçalho e uma linha de > exemplo, > > ou > > > seja, > > > > duas > > > > > linhas a cada tipo de tabela). > > > > > > > > > > > > > > > > > > > > > > > > > > PostgreSQL v9.3: por favor não perca tempo com > versões > > > anteriores, > > > > pois > > > > > sei que > > > > > > todos curtem JSON (!) na OKBr. > > > > > > > > > > Esse é outro problema, a versão que há para > instalar no > > > servidor é o > > > > 9.1. > > > > > Teria que puxar um mais recente dos outros > repositórios e > > rezar > > > para > > > > não > > > > > quebrar outro pacote... > > > > > > > > > > > Se deixar as colunas "de chave" SQL-normais, e as > > demais > > > colunas > > > > > codificadas > > > > > > num campo só com JSON, terá tudo de bom que já > tinha no > > > Mongo. > > > > > > ... e antes de bater o martelo num tabelão > universal, > > > > > > > > > > Teria que ver qual o suporte do SQLAlchemy para > JSON no > > > Postgres. > > > > Porque se > > > > > não for para usar SQLAlchemy teria que reescrever > a API > > atual > > > do GA > > > > também. > > > > > E se fosse para ir por ai, me parece mais razoável > migrar > > tudo > > > para o > > > > > MongoDB > > > > > e pronto... > > > > > > > > > > > > > > > SQLAlchemy (ou o framework-SQL que for) não vai > diferenciar > > tabela > > > bruta > > > > de > > > > > VIEW-SQL, > > > > > a modelagem de dados inclui conceber as VIEWs. > > > > > > > > > > > > > > > > > > > > > > > > > E outra coisa, deixando uma parte em JSON dá para > cruzar > > os > > > dados > > > > depois > > > > > com > > > > > as outras tabelas (ex: receita) "de boa"? Será que > não > > vai dar > > > tanto > > > > > trabalho > > > > > quanto interfacear com o Mongo via FDW? > > > > > > > > > > > - Além disso, pelo que consegui entender no > > servidor, os > > > dados > > > > atuais > > > > > de > > > > > > receita e contratos não estão em um > Postgres, mas > > sim > > > num > > > > MariaDB. > > > > > Logo > > > > > > teríamos que migrá-los também para um > Postgres... > > A não > > > ser > > > > que > > > > > alguém ai > > > > > > defenda deixar tudo no MariaDB. Não sei > como é o > > NoSQL/ > > > GIS > > > > dele... > > > > > > > > > > > > Essa parte é tranquila, posso ajudar. > > > > > > > > > > Em teoria o SQLAlchemy cuidaria disso sozinho. > Seria só > > mudar o > > > link > > > > para o > > > > > BD > > > > > nele e reimportar os dados. Mas nunca se sabe o > que pode > > > acontecer... > > > > > > > > > > > > > > > Mais uma vez, vamos documentar: outra coisa simples de > > colocar na > > > Wiki é > > > > uma > > > > > descrição sucinta do atual modelo de dados, para > conferir o > > grau de > > > > impacto (se > > > > > zero ou mais) das mudanças propostas. > > > > > > > > > > > > > > > > > > > > > Infra da OKBr: é um problema sério que nasce com > os > > problemas > > > de > > > > > governança. > > > > > > Na minha opinião deveria haver uma infra mínima > > unificada, > > > decente > > > > e para > > > > > todos > > > > > > os projetos. > > > > > > > > > > Bom, esse servidor É uma infra mínima unificada, e > esse é > > o > > > problema: > > > > puxa > > > > > de > > > > > um lado, quebra do outro... Isso quando não quebra > sem > > nem > > > ninguém > > > > entender > > > > > o > > > > > que foi. > > > > > > > > > > > > > > > Servidores com bom suporte a PostreSQL custam nos EUA o > > máximo > > > US$10/mês > > > > (!!) > > > > > (para esse volume de dados e freq. de acesso que temos) > > > > > é um absurdo a OKBr não ser capaz de oferecer isso > para os > > > projetos.. > > > > Mais > > > > > absurdo ainda um projeto de ~R$500k > > > > > não poder oferecer isso ao desenvolvedor. > > > > > ... Como eu coloquei antes, é uma questão de > governança-OKBr > > (todos > > > os > > > > > projetos)... > > > > > Eu sugiro uma reunião técnico-deliberativa > (deliberativa!) > > sobre o > > > > assunto... > > > > > :-) > > > > > > > > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > okfn-br mailing list > > > > > [email protected] > > > > > https://lists.okfn.org/mailman/listinfo/okfn-br > > > > > Unsubscribe: > https://lists.okfn.org/mailman/options/ > > okfn-br > > > > > > > > > > > > > > _______________________________________________ > > > > okfn-br mailing list > > > > [email protected] > > > > https://lists.okfn.org/mailman/listinfo/okfn-br > > > > Unsubscribe: > https://lists.okfn.org/mailman/options/okfn-br > > > > > > > > > > > _______________________________________________ > > > okfn-br mailing list > > > [email protected] > > > https://lists.okfn.org/mailman/listinfo/okfn-br > > > Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br > > > > > > > > _______________________________________________ > > okfn-br mailing list > > [email protected] > > https://lists.okfn.org/mailman/listinfo/okfn-br > > Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br > > > > > > > > > > -- > > Luiz Armesto > _______________________________________________ > Gastosabertos mailing list > [email protected] > https://lists.okfn.org/mailman/listinfo/gastosabertos > -- Luiz Armesto
_______________________________________________ okfn-br mailing list [email protected] https://lists.okfn.org/mailman/listinfo/okfn-br Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
