[Gastosabertos] Organização dos dados geoespaciais

Quarta Julho 15 02:15:04 UTC 2015

Criei a coluna extra para marcar o que já se tentou localizar, e os métodos
que você falou para pegar pontos/regiões (mais ainda não testei esses últimos,
provavelmente estão errados...) [0].

Sobre esse SRID, erm... Como uso isso?

Há um tempo atrás tínhamos conversado sobre como mandar os pontos para serem
colocados no mapa, de forma a não ser um pacote de dados muito grande.
Esse endpoint "minlist" [1] busca fazer isso mandando todos os pontos mapeados
de um ano. Porém, apenas a lat, lon e o UID deles. Assim é o mínimo para o
mapa conseguir desenhar todos eles e poder pedir mais informações quando
clicados. Aparentemente funciona, mas é um bom jeito de fazer mesmo?
(Sei que você tinha dito para dar preferência ao GeoJSON, mas nesse caso achei
melhor otimizar e mandar as lat,log direto... Ou será que deveria montar um
GeoJSON com todos os pontos dentro antes de enviar?)

[0]: https://github.com/andresmrm/gastos_abertos/blob/master/gastosabertos/execucao/models.py
[1]: https://github.com/andresmrm/gastos_abertos/blob/master/gastosabertos/execucao/views.py#L46-L59

Quoting Luiz Armesto (2015-07-14 13:05:25)
> 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