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.
