[okfn-br] Status do MootiroMaps

Terça Junho 10 14:13:24 UTC 2014

Olá a todos,

legal os questionamentos, vou tentar responder a alguns (a Dani pode me
ajudar mais aqui já que sempre cuidou mais da parte de especificações e
funcionalidades).

Quando o MootiroMaps começou haviam menos alternativas do que tem hoje, uma
das primeiras coisas que a Dani e o Edgar fizeram foi estudar alternativas,
e eles chegaram a conclusão de que valia a pena na epóca construir o Maps.
Dado o impulso que tomou vemos que foi uma decisão certa.
Hoje em dia, com muito mais experiência na área nós vimos que nem sempre as
funcionalidades que achavamos que os usuários gostariam são as que
realmente são mais usadas.

Por exemplo, hoje vemos claramente que dentro do Maps, as pessoas preferem
trabalhar com projetos de mapeamento, não com dados isolados. No Meppit
isso se torna a maneira padrão de trabalhar, seria algo como "Mapeamento
Temático". Fazendo análogia com apps de música, seriam como playlists,
assim como em apps como o spotify suas músicas deveriam sempre estar em
playlists, e você reaproveita-las em múltiplas playlists. No Meppit seus
dados fazem parte sempre de um mapa, e eles podem ser reaproveitados entre
diferente projetos de mapeamento.
Por exemplo, se quero fazer um mapeamento de pontos aonde posso treinar em
São Paulo, e um outro mapa específico de ginásios de CrossFit, posso
reaproveitar esse dados entre múltiplos mapas.

Outra coisa que percebemos, é diferentemente do que achavamos, a forma
principal de trabalho que os usuários fizeram dos mapas não foi mapeando
comunidades (o que era o foco do MootiroMaps e é o foco da localwiki por
exemplo). As pessoas fizeram mais uso de projetos, como mapeamentos de
redes de conselhos tutelares e crianças em necessidade para ligar os
tutelares a essas crianças de maneira mais eficiente.
Daí vem a idéia de "mapeamento temático".
Você pode criar mapas para quaisquer funcionalidaes, desde apps de
restaurantes e comida, a esportes, conselhos tutelares, ou comunidades.

Outro ponto, é o mapeamento em batches (importação massiva de dados). A
grande maioria dos dados do Maps foram importados via planilhas e KMLs, e
depois editados dentro da ferramenta. Boa parte dessas ferramentas
vislumbra o mapeamento manual.

Também estamos focando em suporte a dados não estruturados (ou
semi-estruturados), por exemplo ter um campo aonde você pode inserir dados
em yaml que podem depois ser indexados, procurados ou separados. Por
exemplo posso subir um monte de bares, com informações de horário e preço,
e mostrar um mapa interessantes levando em consideração isso (criar um
heatmap de preços na cidade, ou sei lá).

Outra funcionalidade, muito requisitada e sendo desenvolvida a principio é
a definição de relações genéricas entre os objetos. Por exempo, dado um
mapa de ongs quais ajudam quais, investem em quais, são parceiras e coisas
do tipo. Essa é uma funcionalidade que apesar de parecer simples, se
mostrou incrivelmente dificil de implementar num sistema legado que não foi
pensado do principio para isso (você tem relações polimorficas, entre
multiplos objetos, que não são pre-definidas).

Quanto a facilidade de instalação e de modificar a interface. Estamos
dedicando esforço adicional para a interface ficar separada em partials
(tanto nos templates do Rails, qdo stylesheets do sass) para  que seja
fácil de encontrar e modificar quaisquer elemento. A instalação do Meppit é
substancialmente mais simples, desde o principio estamos mantendo um
arquivo de bootstrap (que nós mesmo usamos em desenvolvimento, com o
Vagrant) que deverá cuida disso. O MootiroMaps tinha uma ambiente realmente
complexo, por exemplo para subi-lo precisamos ter no ambiente python, ruby,
nodejs, java (ES) e erlang (rabbitmq). Nos estamos evitando adicionar
quaisquer dependências externas pesadas, justamente para manter o sistema o
mais simples possível.

Como dito anteriormente, o Meppit deverá ser repositório de dados, que vc
pode acessar a partir de qquer interface web ou mobile.

Futuramente planejamos funcionalidades como harvesting para compartilhar
dados entre multiplas instâncias do servidor. Formatos como o RDF para
trabalhar com linked data. Camadas de visualização, hierarquia entre
polígonos, embeding (um dos motivos para mantermos o código js do Mapa em
uma lib separada) e etc.

Um último ponto, e talvez o principal é manutenção e qualidade. Criar um
projeto de mapeamento com escopo pequeno e tempo de vida curto é simples.
Você junta qquer php, ou plugin de wordpress e voilá, vc tem seu mapa. Mas
fazer um projeto de grande porte, suficiente genérico, que suporte uma
quantidade massiva de dados (temos poligonos de um único objeto no Maps com
mais de 10000 pontos!) e que seja fácil de manter no longo prazo, não é
nada simples. Por isso escolhemos ferramentas "melhores" que encorajem boas
práticas visando essa manutebilidade. A locawiki por exemplo, quase não tem
testes automatizados (já passamos por isso, e sabemos o inferno que é
manter um projeto assim no longo prazo), isso é algo que tem q ser feito do
princípio. E boa parte dessas ferramentas não levam isso muito em conta.
(Isso pq a localwiki é feita em Python que tem uma cultura um pouco melhor
sobre testes e qualidade, agora projetos de php que o pessoal praticamente
não testa, e tem um compromentimento mais baixo com qualidade, é ainda pior
.. em dezembro e janeiro eu entrei no repósito da maioria dessas
ferramentase, avaliando a possibilidade de extende-las e não foi mto
agradável a experiência).
Outro aspecto é escala de dados, o Luiz dedicou muito tempo otimizando o
código de Mapa para suportar quantidades grandes de dados, boa parte dessas
ferramentas trabalham com quantidades bem menores de geometrias do que
temos hoje no Maps (e bem menor do que as importações que planejamos fazer
no Meppit). Isso também influência na idéia de termos mapas temáticos e não
um super mapão com tudo, pois com mtos dados, um único mapa gigante se
torna inviável para o usuário.

No Meppit nós temos um código continuamente análisado a cada PR no
Codeclimate, continuamente testado no TravisCI, com cobertura de testes de
mais de 96%. A cada PR, é avaliado automaticamente: qualidade, duplicação,
brechas de segurança, cobertura de tests e por ai vai.
Estamos fazendo dessa forma, pq não queremos ter que desenvolver outro
sistema desses, e sim um sistema único e bem escrito que seja fácil de
extender futuramente.
https://codeclimate.com/github/it3s/meppit
https://coveralls.io/r/it3s/meppit
https://travis-ci.org/it3s/meppit

Acho que expliquei mais ou menos algumas das razões.

abs

Anderson

2014-06-10 10:16 GMT-03:00 Andres MRM <andres em inventati.org>:

> @Daniela: Claro, quando pudermos te avisamos. =)
> []s!
>
> _______________________________________________
> okfn-br mailing list
> okfn-br em lists.okfn.org
> https://lists.okfn.org/mailman/listinfo/okfn-br
> Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
>

-- 
Anderson Pierre Cardoso

<http://goog_730476546>
http://andersoncardoso.github.io  |  @apierre_cardoso
<http://twitter.com/apierre_cardoso>
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/okfn-br/attachments/20140610/808fa109/attachment-0005.html>