[okfn-br] Status do MootiroMaps

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

Mas concordo que deve-se tomar o cuidado de não adotar tecnologias só
porque é modinha. Estou notando que isso parece ser uma tendência entre
programadores mais inexperientes.

Em 10 de junho de 2014 12:22, Everton Zanella Alvarenga <tom em okfn.org.br>
escreveu:

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

-- 
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/0a824fcf/attachment-0005.html>