[Gastosabertos] Organização dos dados geoespaciais

Quarta Julho 15 06:05:09 UTC 2015

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

>
> 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?
>

SRID é o identificador do sistema de referência que o PostGIS vai usar
internamente. É importante usar o mesmo sistema nas diversas colunas e
saber em qual sistema estão os dados que serão importados e fazer a
conversão se necessário.

>
> 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?)
>

A vantagem de mandar GeoJSON é que é um formato já estabelecido e que tanto
o PostGIS quanto o leaflet possuem suporte.

O grande problema na versão anterior era que era mandada praticamente a
base de dados inteira de uma vez só. Para minimizar o tamanho da
transferência inicial de dados e, assim, tornar o carregamento mais rápido
tem duas coisas a se tomar cuidado. Uma é transferir apenas o conjunto de
dados necessários e a outra é, para cada dado, transmitir apenas os campos
necessários.

Do modo que você fez você está cumprindo o segundo ponto, transmitindo só
os campos necessários, e ainda está economizando bytes mandando apenas o
estritamente necessário. Mas em contrapartida está adicionando a
complexidade de usar um formato próprio e não algo padronizado que já
possui suporte na biblioteca javascript usada no cliente.

O GeoJSON é mesmo mais verborrágico do que o modo que você fez, mas a
estrutura a mais que ele utiliza é repetida várias e várias vezes na lista
de dados, o que o torna um ótimo candidato a compactação. Então antes de
querer otimizar na mão, por que não tentamos fazer a API aceitar o
cabeçalho "Accept-Encoding: gzip" e mandar o conteúdo campactado?

Veja uma simulação que fiz no console do python:

Criei uma lista de 100 "pontos" aleatórios como uma lista de tuplas de 3
elementos, o primeiro é uma string uuid, o segundo e o terceiro são floats
com poucas casas decimais

[(u'2afb3d8d-4ac1-41f9-9eb1-8dffde3335e8', 75.375, 54.0), ...]

Criei então uma lista de dicionários no formato do GeoJSON com os mesmos
valores

[{'geometry': {'coordinates': [75.375, 54.0], 'type': 'Point'},
 'properties': {'uid': u'2afb3d8d-4ac1-41f9-9eb1-8dffde3335e8'},
 'type': 'Feature'}, ...]

bem mais verboso, certo?

Transformei cada uma das duas coleções em json e vi o tamanho de cada uma,
lembrando que ambas representam os mesmo 100 "pontos" só com formatação
diferente.

lista simples: 5882
geojson: 14882

O geojson ficou com 2.53 vezes o tamanho do formato simples. Diferença
significativa. Mas agora vamos compactar os dois com zlib e avaliar
novamente a diferença

lista simples compactada: 3020
geojson compactado: 3282

Agora o geojson ficou com 1.09 vezes o tamanho do formato simples. Uma
diferença desprezível para uma vantagem enorme de se usar um formato
estabelecido ;)

>
> [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
> _______________________________________________
> 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/20150715/c3d667e7/attachment-0003.html>