[Gastosabertos] Organização dos dados geoespaciais

Terça Julho 14 16:05:25 UTC 2015

Se são poucas regiões e poucos pontos, então a principio acho que podemos
usar queries espaciais mesmo.

Então eu faria assim:

Primeiro criaria um método ou uma property no model de região que
devolveria o resultado da query dos pontos que estão naquela região.
Faria o mesmo no model de ponto para retornar a região. (devolva o
resultado da query e não diretamente os pontos/regiões, para que seja
possível fazer novas filtragens a partir do resultado devolvido)

Sempre que precisar dos pontos de uma região ou das regiões de um ponto eu
usaria esses métodos. Desse modo se mais pra frente tiver outras
necessidades, ou percebermos problema de performance, e a modelagem for
alterada, é só mudar a implementação desses dois métodos.

PS.: Não esquece de definir explicitamente o srid das colunas geometricas.

2015-07-14 12:40 GMT-03:00 Andres MRM <andres em inventati.org>:

>
> Entendo. A ideia que tenho é usar as subprefeituras como regiões fixas. E
> colocar em que subprefeitura cada despesa está.
> Ou seja, seriam 32 (?) regiões e ~10K pontos distribuídos nelas.
> Mas isso é para dar as funcionalidades básicas que comentei anteriormente,
> não
> sei se vamos além disso...
>
>
> Quoting Luiz Armesto (2015-07-14 12:04:17)
> > As regiões são fixas ou com o tempo serão incluidas regiões novas? São
> apenas
> > as regiões oficiais ou terá regiões personalizadas? A relação seria de
> uma
> > região para muitos pontos ou de muitas regiões para muitos pontos?
> >
> > Tem que avaliar e decidir a modelagem. Se a relação entre ponto e região
> será
> > armazenada no banco de dados ou será obtida por query espacial. Para
> decidir
> > isso melhor seria bom ter uma ideia da quantidade de pontos que serão
> > armazenados, quantidade de regiões, casos de uso e restrições, para
> saber qual
> > opção é melhor.
> >
> > Se teremos muitos pontos e as regiões são fixas, então armazenar a
> relação é
> > uma boa pois é mais barato fazer uma query por relação do que uma query
> > espacial, principalmente quando temos muitos pontos.
> >
> > Se não tiver tantos pontos, a query espacial não é tão custosa e
> armazenar a
> > relação pode ser desnecessário.
> >
> > Se as regiões não são fixas, caso seja salva a relação com pontos
> teremos que
> > cada vez que uma região for adicionada/editada/removida atualizar as
> relações
> > com os pontos. Se for usada query espacial, então não tem problema ter
> > alterações nas regiões, sempre pegaremos as relações corretas.
> >
> > 2015-07-14 11:41 GMT-03:00 Andres MRM <andres em inventati.org>:
> >
> >
> >     Quoting Luiz Armesto (2015-07-14 11:30:49)
> >     > Cria uma outra coluna e salva nela o status do processamento. Não
> é uma
> >     boa
> >     > usar o valor da coluna "point" para inferir algo que seria melhor
> >     armazenado
> >     > explicitamente.
> >
> >     Ok.
> >
> >     > Como estamos usando um banco relacional, o melhor é criar uma
> tabela de
> >     regiões
> >     > e relacionar execucao com regiao.
> >     >
> >     > Qual é o uso de armazenar em qual regiao esta uma execucao?
> agilizar
> >     alguma
> >     > filtragem ou busca sem precisar fazer query espacial?
> >
> >     Erm... Não sei bem. Imagino que em alguns momentos vamos querer
> mostrar em
> >     que
> >     região está uma despesa.
> >     Por exemplo, quando clicar em um ponto e mostrar todas as
> informações dele,
> >     a
> >     região deve estar lá. Ou então quando quisermos mostrar, em um mapa,
> o
> >     total
> >     gasto em cada região.
> >     Como essas informações seriam obtidas?
> >     _______________________________________________
> >     Gastosabertos mailing list
> >     Gastosabertos em lists.okfn.org
> >     https://lists.okfn.org/mailman/listinfo/gastosabertos
> >
> >
> >
> >
> > --
> > Luiz Armesto
> _______________________________________________
> Gastosabertos mailing list
> Gastosabertos em lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/gastosabertos
>

-- 
Luiz Armesto
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/gastosabertos/attachments/20150714/390e412f/attachment-0003.html>