[okfn-br] Status do MootiroMaps

Terça Junho 10 15:22:05 UTC 2014

Rafael,

usar PHP pois é mais fácil de instalar não é um bom argumento técnico para
a decisão da tecnologia a ser usada. :)

Anderson,

vou responder com calma seus argumentos depois. Ainda estou pouco
convencido da necessidade de mudança e vamos mais a fundo nisso.

O LocalWiki vai mudar algumas coisas na tecnologia. Vale a pena uma
discussão com o Philip, que conseguiu deixar o projeto mais sustentável que
o Mootiro e formou, de fato, uma comunidade.

Vocês chegaram a pensar o que falhou no quesito comunidade em relação ao
Mootiro? Quais as conclusões?

Tom

Em 10 de junho de 2014 12:13, Rafael Pezzi <rafael.pezzi em ufrgs.br> escreveu:

>  Oi Pessoal,
>
> Fico muito contente que estão fazendo a transição para o OSM (Open Street
> Map). A sobreposição de dados não livres aos dados creative commons da
> comunidade no próprio site é algo realmente grave, pois a inconsistência
> legal já estava feita na fonte.
>
> Como o Abdo, também levanto o questionamento sobre reescrever o código do
> zero ao invés de colaborar com projetos existentes.
>
> Um projeto que pode servir de inspiração e referência é o SmartCitizen:
> http://www.smartcitizen.me/
> O código está todo disponível no github:
> https://github.com/fablabbcn/SmartCitizen.me
>
> Já que a questão de desenvolvimento ainda está aberta, gostaria de sugerir
> que o projeto fosse elaborado em php ao invés de ruby, pois php e muito
> mais fácil de instalar, estando disponível em qualquer serviço de
> hospedagem - o que pode facilitar a adoção.
>
> Abraço,
> Rafael
>
>
>
>
> Em 10-06-2014 11:13, Anderson Cardoso escreveu:
>
>
> 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>
>
>
>
> _______________________________________________
> okfn-br mailing listokfn-br em lists.okfn.orghttps://lists.okfn.org/mailman/listinfo/okfn-br
> Unsubscribe: https://lists.okfn.org/mailman/options/okfn-br
>
>
> _______________________________________________
> 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
>
>

-- 
Everton Zanella Alvarenga (also Tom)
Open Knowledge Brasil - Rede pelo Conhecimento Livre
http://br.okfn.org
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://lists.okfn.org/pipermail/okfn-br/attachments/20140610/cfe4dee4/attachment-0005.html>